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

List:       macports-users
Subject:    Re: ruby_select is broken
From:       Lenore Horner <lenorehorner () sbcglobal ! net>
Date:       2021-10-09 14:45:47
Message-ID: 734599ED-6B40-4473-8F2A-2C037AAB6545 () sbcglobal ! net
[Download RAW message or body]

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]