[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-users
Subject:    Re: ruby_select is broken
From:       Ryan Schmidt <ryandesign () macports ! org>
Date:       2021-10-05 21:54:36
Message-ID: 0099A973-4395-475D-A4A6-F2C1FDB5B64D () macports ! org
[Download RAW message or body]

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



[prev in list] [next in list] [prev in thread] [next in thread]