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