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