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
