ruby_select is broken

Ian Wadham iandw.au at gmail.com
Sun Oct 3 07:58:43 UTC 2021


> On 2 Oct 2021, at 6:29 pm, Ryan Schmidt <ryandesign at macports.org> 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
        }
    }

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 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.

>> 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.

Cheers,
Ian Wadham.





More information about the macports-users mailing list