Thank you, Lenore. > On 10 Oct 2021, at 1:45 am, Lenore Horner = wrote: >=20 > It looks to me like the actual problem is that ruby30 doesn=E2=80=99t = produce any notes about how to use port select unlike the pythonxx = installations. I=E2=80=99ve filed a trac ticket about adding a note to = ruby so that other people won=E2=80=99t have Ian=E2=80=99s problem. > Lenore >=20 >> On Oct 8, 2021, at 22:20, Ian Wadham wrote: >>=20 >> Hi Ryan and Bill, >>=20 >> Let=E2=80=99s all stand back a bit and get a little perspective. >>=20 >> Firstly, the =E2=80=9Csudo port select=E2=80=9D command works fine, = but it can take a while for a user to discover it when he/she needs it. >>=20 >> 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. >>=20 >> I have been a developer for many years and have many languages under = my belt, but alas not Ruby. >>=20 >> Flutter=E2=80=99s 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.=20 >>=20 >> The Getting Started page on CocoaPods=E2=80=99 website says to use = Ruby as provided by MacOS, using command "sudo gem install cocoapods=E2=80= =9D. 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. >>=20 >> 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. >>=20 >> When I installed the MacPorts package called =E2=80=9Cruby=E2=80=9D I = got a version that was even more out-of-date than Apple=E2=80=99s (1.8 = versus 2.6). When I installed the MacPorts package called =E2=80=9Cruby27=E2= =80=9D I got nothing I could run: no =E2=80=9Cgem=E2=80=9D 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 =E2=80=9Cport select=E2=80=9D command at = that stage. Why would I have? Until recently I have been a C++ = developer. >>=20 >> 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 =E2=80=9Cgem2.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=E2=80=99s portfile = and discovered the existence of the =E2=80=9Cport select=E2=80=9D = command. Even then it is not easy to find. There are about a dozen = occurrences of the word =E2=80=9Cselect=E2=80=9D in the =E2=80=9Cman = port=E2=80=9D output and I was wondering for a moment if =E2=80=9Cport = select=E2=80=9D actually exists or if it is just some internal function = of portfiles and MacPorts scripts. >>=20 >> All of the above occupied several frustrating days of my time. >>=20 >> So this is why I say the portfile for ruby_select is broken. Several = =E2=80=9Cruby$NN=E2=80=9D packages depend on it. >>=20 >> MacPorts=E2=80=99 Python gives a new user something he/she can = immediately use, with a sensible default version being automatically = =E2=80=9Cselected=E2=80=9D (in the MacPorts sense), but MacPorts=E2=80=99 = Ruby does not do any of that. So it fails on the grounds of user = UN-friendliness. At the very least MacPorts=E2=80=99 Ruby installations = should have a Note to inform any new users about the =E2=80=9Cport = select=E2=80=9D command. >>=20 >> All=E2=80=99s 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. >>=20 >> All the best, >> Ian Wadham. >>=20 >>> On 6 Oct 2021, at 8:54 am, Ryan Schmidt = 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: >>>>>=20 >>>>>> MacPorts contains packages of many versions of Ruby, similarly to = the Python and Perl groups, but the corresponding =E2=80=9Cruby_select=E2=80= =9D port does not automatically create the links needed to access = commands =E2=80=9Cruby=E2=80=9D, =E2=80=9Cgem=E2=80=9D etc. I was able = to get around this by using =E2=80=9Csudo port select=E2=80=9D manually, = but would it be possible for someone to fix =E2=80=9Cruby_select=E2=80=9D = so that the ports =E2=80=9Cruby$n=E2=80=9D work properly =E2=80=9Cout of = the box". >>>>>=20 >>>>> 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. >>>>=20 >>>> The helper infrastructure is failing for ports =E2=80=9Cruby$NN=E2=80= =9D. Other ports which have multiple versions available have lines like: >>>>=20 >>>> platform darwin 14 { >>>> post-destroot { >>>> select::install perl ${filespath}/perl5.16-apple.14 >>>> select::install perl ${filespath}/perl5.18-apple.14 >>>> } >>>> } >>>=20 >>> 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.) >>>=20 >>> See https://trac.macports.org/ticket/29763 and = https://trac.macports.org/ticket/60812. >>>=20 >>> 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. >>>=20 >>>=20 >>>> or >>>>=20 >>>> foreach python $apple_pythons { >>>> select.entries-append [list python {*}$python] >>>> } >>>>=20 >>>> in their *_select portfiles. Presumably these automate the = redirecting of commands such as =E2=80=9Cperl' or =E2=80=9Cpython" to = the appropriate version. >>>=20 >>> 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.) >>>=20 >>> 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. >>>=20 >>> 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 ..." >>>=20 >>>=20 >>> * with the exception of the "root" ports which have been designed = incorrectly; see https://trac.macports.org/ticket/49752 >>>=20 >>>=20 >>>> The ruby_select portile just has: >>>>=20 >>>> destroot { >>>> select::install ruby ${filespath}/base >>>> select::install ruby ${filespath}/none >>>> } >>>>=20 >>>> which does not redirect the commands =E2=80=9Cruby=E2=80=9D or = =E2=80=9Cgem=E2=80=9D to the appropriate version when you have installed = the port =E2=80=9Cruby27=E2=80=9D for example. Instead, =E2=80=9Cwhich = ruby=E2=80=9D or =E2=80=9Cwhich gem=E2=80=9D always finds the Apple = version of Ruby, which is now deprecated according to the Catalina = Release Notes... >>>>=20 >>>> Actually my first =E2=80=9Cworkaround" was to use a Bash alias, but = then I figured there must be a MacPorts command to fix it, perhaps = called =E2=80=9Cport select=E2=80=9D=E2=80=A6 :-) >>>=20 >>>=20 >>>> In any event, the portile for ruby_select is not working on ports = like =E2=80=9Cruby26=E2=80=9D, =E2=80=9Cruby27=E2=80=9D, etc. >>>=20 >>> 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: >>>=20 >>>=20 >>> $ 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 >>>=20 >>>=20 >>>=20 >>>>>> Also, the port actually called =E2=80=9Cruby=E2=80=9D is very old = (version 1.8.7) and =E2=80=9Cport notes ruby=E2=80=9D deprecates it. = Should it be removed from MacPorts? >>>>>=20 >>>>> If nobody needs it, I suppose it could be removed. Do you know = that nobody needs it? I don't know that. >>>>>=20 >>>>>> Or reincarnated as =E2=80=9Cruby18=E2=80=9D, dropping = =E2=80=9Cruby186=E2=80=9D as well? >>>>>=20 >>>>> If it ain't broke, don't fix it? >>>>=20 >>>> Port =E2=80=9Cruby_select=E2=80=9D is broken. >>>>=20 >>>> Port =E2=80=9Cruby=E2=80=9D 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. >>>=20 >>> As far as I can determine, the ruby_select port works as intended. >>>=20 >>> "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. >>>=20 >>> 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. >>>=20 >>> * = https://github.com/macports/macports-ports/commit/f6a29d1e4f0349b8485073c4= 670451e399d4d5bb >>>=20 >>=20 >=20