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

List:       macports-users
Subject:    Re: ruby_select is broken
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2021-10-10 20:13:02
Message-ID: C3EC7365-DEA9-47D3-9538-A96E7E92E5B1 () gmail ! com
[Download RAW message or body]

Thank you, Lenore.

> On 10 Oct 2021, at 1:45 am, Lenore Horner <LenoreHorner@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.au@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 <ryandesign@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
> > >  
> > 
> 


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