ruby_select is broken

Sun Oct 10 20:13:02 UTC 2021

Thank you, Lenore.

> On 10 Oct 2021, at 1:45 am, Lenore Horner <LenoreHorner at sbcglobal.net> wrote:
> 
> It looks to me like the actual problem is that ruby30 doesn’t produce any notes about how to use port select unlike the pythonxx installations.  I’ve filed a trac ticket about adding a note to ruby so that other people won’t have Ian’s problem.
> Lenore
> 
>> On Oct 8, 2021, at 22:20, Ian Wadham <iandw.au at gmail.com> wrote:
>> 
>> Hi Ryan and Bill,
>> 
>> Let’s all stand back a bit and get a little perspective.
>> 
>> Firstly, the “sudo port select” command works fine, but it can take a while for a user to discover it when he/she needs it.
>> 
>> A few weeks ago I read about a package called Flutter and its underlying language called Dart. They are supplied freely and openly by Google. Their libraries, tools, code fragments and language are claimed to make it possible to write GUI applications that can run on almost any device, using the same source code for every device. Flutter can be used on Linux and Windows to build apps for Android devices or for Windows/Linux desktops. It can be used on MacOS to build apps for iPhones, iPads and the MacOS desktop. I live Melbourne, Australia, a city that has just established a world record for days in COVID lockdown. So I was anxious to relieve the boredom by trying out Flutter and Dart.
>> 
>> I have been a developer for many years and have many languages under my belt, but alas not Ruby.
>> 
>> Flutter’s pre-requisites on MacOS are Xcode 12 and CocoaPods. The latter depends on Ruby. I had to upgrade my MacOS from High Sierra to Catalina to get Xcode 12, which in itself was quite a drama, but I migrated MacPorts and my MacPorts apps without any trouble. 
>> 
>> The Getting Started page on CocoaPods’ website says to use Ruby as provided by MacOS, using command "sudo gem install cocoapods”. But that does not work and will never work again, because the MacOS version of Ruby is too old for building CocoaPods and is going to be phased out anyway in later versions of MacOS, as mentioned in the Catalina Release Notes.
>> 
>> As noted above, I was a complete newcomer to Ruby (and still am). I did not wish to learn Ruby. I just wanted to install a more recent version of Ruby in order to build CocoaPods and then move on to Flutter and Dart programming, starting with (you guessed it) Hello World.
>> 
>> When I installed the MacPorts package called “ruby” I got a version that was even more out-of-date than Apple’s (1.8 versus 2.6). When I installed the MacPorts package called “ruby27” I got nothing I could run: no “gem” command down in /opt/local/bin, so I uninstalled ruby27 and went looking elsewhere for a Ruby installer (Google, Stack Overflow, Homebrew, RVM, rbenv), but always I had the nagging thought that surely MacPorts would not install a package and then have no way you could use it. I had of course never heard of and never used the “port select” command at that stage. Why would I have? Until recently I have been a C++ developer.
>> 
>> Anyway I re-installed ruby27 and did a bit of digging around, finding that gem had been installed in /opt/local/bin as gem2.7, so I ran the command “gem2.7" and CocoaPods built and installed just fine. Then I wondered how does MacPorts handle other languages with multiple versions: I never had a problem a few years back when I downloaded a Python source program from the Internet and ran it, after using MacPorts to install Python. So I had a look at python_select’s portfile and discovered the existence of the “port select” command. Even then it is not easy to find. There are about a dozen occurrences of the word “select” in the “man port” output and I was wondering for a moment if “port select” actually exists or if it is just some internal function of portfiles and MacPorts scripts.
>> 
>> All of the above occupied several frustrating days of my time.
>> 
>> So this is why I say the portfile for ruby_select is broken. Several “ruby$NN” packages depend on it.
>> 
>> MacPorts’ Python gives a new user something he/she can immediately use, with a sensible default version being automatically “selected” (in the MacPorts sense), but MacPorts’ Ruby does not do any of that. So it fails on the grounds of user UN-friendliness. At the very least MacPorts’ Ruby installations should have a Note to inform any new users about the “port select” command.
>> 
>> All’s well that ends well. I am now getting up to speed on Flutter and Dart and have run the demo source code on my MacBook desktop and on an Xcode Simulator of my iPhone. I am also progressing well on porting one of my C++ apps to Flutter and Dart.
>> 
>> All the best,
>> Ian Wadham.
>> 
>>> On 6 Oct 2021, at 8:54 am, Ryan Schmidt <ryandesign at macports.org> wrote:
>>> On Oct 3, 2021, at 02:58, Ian Wadham wrote:
>>>> On 2 Oct 2021, at 6:29 pm, Ryan Schmidt wrote:
>>>>> On Sep 25, 2021, at 23:14, Ian Wadham wrote:
>>>>> 
>>>>>> MacPorts contains packages of many versions of Ruby, similarly to the Python and Perl groups, but the corresponding “ruby_select” port does not automatically create the links needed to access commands “ruby”, “gem” etc. I was able to get around this by using “sudo port select” manually, but would it be possible for someone to fix “ruby_select” so that the ports “ruby$n” work properly “out of the box".
>>>>> 
>>>>> I don't understand what you mean. ruby_select (and all _select ports) are helper infrastructure so that "port select" works. Using "port select" is not a workaround; it is *the* way to select a particular version of a set of ports.
>>>> 
>>>> The helper infrastructure is failing for ports “ruby$NN”. Other ports which have multiple versions available have lines like:
>>>> 
>>>> platform darwin 14 {
>>>>     post-destroot {
>>>>         select::install perl ${filespath}/perl5.16-apple.14
>>>>         select::install perl ${filespath}/perl5.18-apple.14
>>>>     }
>>>> }
>>> 
>>> These lines are from the perl_select port. I'm surprised to discover that we still have such a port, since the perl ports in MacPorts are unique and do not participate in the "port select" mechanism. The perl ports predate the select mechanism and switching them to use that mechanism would cause lots of breakage. (A zillion ports depend on the existence of an executable (or symlink) called "perl" in the path and expect the perl5 port to provide it. If we remove the perl5 port and instead allow the select mechanism to be responsible for providing the perl executable (symlink) then ports could not depend on it. Ports are not permitted to rely on the effects of the select mechanism because the select mechanism is intended for the use of users, not for the use of other ports.)
>>> 
>>> See https://trac.macports.org/ticket/29763 and https://trac.macports.org/ticket/60812.
>>> 
>>> Since the perl_select port has never worked correctly, anything done by the perl_select port should not be construed as an example of how the select mechanism does or should work. To avoid confusion, perl_select should probably be removed since nobody has fixed it over the past decade.
>>> 
>>> 
>>>> or
>>>> 
>>>> foreach python $apple_pythons {
>>>>     select.entries-append [list python {*}$python]
>>>> }
>>>> 
>>>> in their *_select portfiles. Presumably these automate the redirecting of commands such as “perl' or “python" to the appropriate version.
>>> 
>>> The select mechanism allows the user to select which version of a collection of ports they want to use when they type the unversioned command(s). For example, the python39 port installs /opt/local/bin/python3.9. If the user just types "python", they get /usr/bin/python. Maybe the user wanted "python" to give them /opt/local/bin/python3.9. If so, they would run "sudo port select python python39" which will create a symlink /opt/local/bin/python pointing to /opt/local/bin/python3.9. (There may be many other supporting files that get symlinked as well.)
>>> 
>>> The python select mechanism also allows the user to indicate that they would like to create symlinks to whatever version(s) of python may be included in their version of macOS. For example, "sudo port select python python27-apple" creates a symlink at /opt/local/bin/python pointing to /usr/bin/python2.7 if the user's version of macOS has /usr/bin/python2.7.
>>> 
>>> The port select mechanism never selects anything automatically*. It is always at the discretion of the user whether they would like to select something, and they do that by running "sudo port select ..."
>>> 
>>> 
>>> * with the exception of the "root" ports which have been designed incorrectly; see https://trac.macports.org/ticket/49752
>>> 
>>> 
>>>> The ruby_select portile just has:
>>>> 
>>>> destroot {
>>>>   select::install ruby ${filespath}/base
>>>>   select::install ruby ${filespath}/none
>>>> }
>>>> 
>>>> which does not redirect the commands “ruby” or “gem” to the appropriate version when you have installed the port “ruby27” for example. Instead, “which ruby” or “which gem” always finds the Apple version of Ruby, which is now deprecated according to the Catalina Release Notes...
>>>> 
>>>> Actually my first “workaround" was to use a Bash alias, but then I figured there must be a MacPorts command to fix it, perhaps called “port select”… :-)
>>> 
>>> 
>>>> In any event, the portile for ruby_select is not working on ports like “ruby26”, “ruby27”, etc.
>>> 
>>> So "sudo port select ruby ruby26" does not work for you? "sudo port select ruby ruby27" does not work? What happens when you run them? If they do not create the expected symlinks then indeed that is broken and you should file a bug report. But it worked for me:
>>> 
>>> 
>>> $ sudo port select ruby ruby26
>>> Selecting 'ruby26' for 'ruby' succeeded. 'ruby26' is now active.
>>> $ ls - l /opt/local/bin/ruby
>>> lrwxr-xr-x  1 root  staff  22 Oct  5 16:38 /opt/local/bin/ruby -> /opt/local/bin/ruby2.6
>>> 
>>> 
>>> 
>>>>>> Also, the port actually called “ruby” is very old (version 1.8.7) and “port notes ruby” deprecates it. Should it be removed from MacPorts?
>>>>> 
>>>>> If nobody needs it, I suppose it could be removed. Do you know that nobody needs it? I don't know that.
>>>>> 
>>>>>> Or reincarnated as “ruby18”, dropping “ruby186” as well?
>>>>> 
>>>>> If it ain't broke, don't fix it?
>>>> 
>>>> Port “ruby_select” is broken.
>>>> 
>>>> Port “ruby” wasted my time because it looked as though it would be the default one to install, but then at the end of installation it deprecated itself.
>>> 
>>> As far as I can determine, the ruby_select port works as intended.
>>> 
>>> "If it ain't broke, don't fix it" was in response to your suggestion to rename the "ruby" port to "ruby18" and drop "ruby186". Yes ruby could be renamed to ruby18 and that would be more consistent and it's probably a good idea since it would reduce confusion, but it would probably be a lot of work to rename it and fix everything that depends on it, and the end result assuming everything goes smoothly would be no difference for the user in how the ports work. The port has a maintainer and is not marked as openmaintainer so any changes must be approved by the maintainer; you could suggest it to them by filing a ticket. If they agree with renaming it, they could do the rename, or you or anyone else could put in the work and submit it as a pull request.
>>> 
>>> With regard to removing ruby186, it was created deliberately "for those who need it for compatibility reasons"*. Granted that was in 2009 so I don't know if anybody still needs it for compatibility reasons. If not, it could be removed, but there are references to it in several other ports which should be removed at the same time. But again, having the ruby186 port available isn't hurting anyone, whereas removing it could potentially break things if someone does need it.
>>> 
>>> * https://github.com/macports/macports-ports/commit/f6a29d1e4f0349b8485073c4670451e399d4d5bb
>>> 
>> 
> 