> On Mar 17, 2024, at 12:57 AM, Austin Ziegler <halosta...@gmail.com> wrote: > > I am most definitely a Ruby expert, but I have yet to run any version of Ruby > from MacPorts (because I use `ruby-build` and `mise` to build versions of > Ruby that I require), and I almost exclusively install Ruby packages via `gem > install`.
You could perhaps try sudo port install ruby33 or whatever needed? I have no idea what is going on with archaic versions, but Ruby 3.1+ through ruby-devel (3.4) should work on every system. > Many gemspecs contain information about the minimum Ruby that they require to > run (mime-types 3 requires Ruby 2+, > https://github.com/mime-types/ruby-mime-types/blob/main/mime-types.gemspec#L20; > diff-lcs advertises compatibility with Ruby 1.8+; app_identity advertises > Ruby 2.7+, but not Ruby 4, > https://github.com/KineticCafe/app_identity/blob/8afdd1caaab8d18032f60416eb62add88d308ee0/ruby/app_identity.gemspec#L21). What I mean is that gemspec files often require a version of some another gem using ~> instead of >= like https://rubygems.org/gems/t That prevents gems from running if a dependency is newer. For example, rb-launchy is at 3.0.0: https://rubygems.org/gems/launchy Then I need to do something like this: https://github.com/macports/macports-ports/blob/c778ebc838a41e5761b76e7c6bc5a7ec3c256ab2/ruby/rb-t/Portfile#L30-L33 Problem is that this is quite painful to deal with for every relevant case. > I don't know whether the Ruby and various gem ports are set up to work like > the Python and package ports (e.g., py311, py311-requests), but as each gem > must be installed into each Ruby, that's the best approach to use (e.g., for > *every* Ruby port, there should be Ruby version ports; rb-diff-lcs and > rb19-diff-lcs should have versions for rb18, rb19, rb20, rb21, rb22, rb23, > rb24, rb25, rb26, rb27, rb30, rb31, rb32, and rb33). > > I also think that the `ruby` port needs to be renamed to `ruby18` and `port > install ruby` should *either* fail (like `port install python` or `port > install python3` does) or it should install the latest stable version > (updated on Christmas Day every year). They are, and everything relevant is rb33-* etc. Unversioned one which use rb18 should re updated or removed: we have no reason to keep Ruby versions prior to 3.0, since 3.0 works on Tiger, and 3.1+ work on Leopard through Sonoma. That also includes PowerPC systems. > *Or* there should be an option with Ruby ports to treat them like non-offline > Go ports and allow them to do `gem install` or `bundle install` for more > complex environments. > > Unfortunately, my tcl isn't really good enough (aside from what bits of Tcl > I’ve done now that I am contributing to MacPorts port maintenance, I last > used Tcl in about 2004) to start working with rethinking the Ruby portgroup > to have something like `ruby.bundle` or `ruby.gems` that works like > `cargo.crates` or `go.vendors`, which would *probably* be the better choice > (and it would pull from `rubygems.org <http://rubygems.org/>` *not* > github.com <http://github.com/>; gems are source distributions most of the > time, although some gems exist that contain precompiled binaries for > hard-to-build dependencies). I think that is done in most of the case already. Only a few Ruby ports use GitHub, and that is either historically (and should be switched to RubyGems) or for a specific reason. https://ports.macports.org/port/rb33-sup/details https://github.com/macports/macports-ports/blob/c778ebc838a41e5761b76e7c6bc5a7ec3c256ab2/ruby/rb-sup/Portfile#L7-L16 Precompiled libs is a problem, unfortunately, and some upstream is not interested to bother fixing it. https://github.com/ankane/lightgbm-ruby/issues/7 In result, that is a broken package.
