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