ruby_select is broken

Tue Oct 5 21:54:36 UTC 2021

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