Thank you, Lenore.
> On 10 Oct 2021, at 1:45 am, Lenore Horner <lenorehor...@sbcglobal.net> wrote:
>
> It looks to me like the actual problem is that ruby30 doesn’t produce any
> notes about how to use port select unlike the pythonxx installations. I’ve
> filed a trac ticket about adding a note to ruby so that other people won’t
> have Ian’s problem.
> Lenore
>
>> On Oct 8, 2021, at 22:20, Ian Wadham <iandw...@gmail.com> wrote:
>>
>> Hi Ryan and Bill,
>>
>> Let’s all stand back a bit and get a little perspective.
>>
>> Firstly, the “sudo port select” command works fine, but it can take a while
>> for a user to discover it when he/she needs it.
>>
>> 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.
>>
>> I have been a developer for many years and have many languages under my
>> belt, but alas not Ruby.
>>
>> Flutter’s 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.
>>
>> The Getting Started page on CocoaPods’ website says to use Ruby as provided
>> by MacOS, using command "sudo gem install cocoapods”. 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.
>>
>> 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.
>>
>> When I installed the MacPorts package called “ruby” I got a version that was
>> even more out-of-date than Apple’s (1.8 versus 2.6). When I installed the
>> MacPorts package called “ruby27” I got nothing I could run: no “gem” 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 “port select” command at that stage. Why would I have?
>> Until recently I have been a C++ developer.
>>
>> 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
>> “gem2.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’s portfile and discovered the existence of the “port
>> select” command. Even then it is not easy to find. There are about a dozen
>> occurrences of the word “select” in the “man port” output and I was
>> wondering for a moment if “port select” actually exists or if it is just
>> some internal function of portfiles and MacPorts scripts.
>>
>> All of the above occupied several frustrating days of my time.
>>
>> So this is why I say the portfile for ruby_select is broken. Several
>> “ruby$NN” packages depend on it.
>>
>> MacPorts’ Python gives a new user something he/she can immediately use, with
>> a sensible default version being automatically “selected” (in the MacPorts
>> sense), but MacPorts’ Ruby does not do any of that. So it fails on the
>> grounds of user UN-friendliness. At the very least MacPorts’ Ruby
>> installations should have a Note to inform any new users about the “port
>> select” command.
>>
>> All’s 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.
>>
>> All the best,
>> Ian Wadham.
>>
>>> On 6 Oct 2021, at 8:54 am, Ryan Schmidt <ryandes...@macports.org> 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:
>>>>>
>>>>>> 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
>>>
>>
>
