Ruby question: solution for dependency version specs?

[Sergio Had]

> On Mar 17, 2024, at 12:57 AM, Austin Ziegler <halostatue at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20240317/cc1e9953/attachment-0001.htm>