Ruby question: solution for dependency version specs?

Sergio Had vital.had at
Sat Mar 16 19:28:48 UTC 2024

> On Mar 17, 2024, at 12:57 AM, Austin Ziegler <halostatue at> 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+,; diff-lcs advertises compatibility with Ruby 1.8+; app_identity advertises Ruby 2.7+, but not Ruby 4,

What I mean is that gemspec files often require a version of some another gem using ~> instead of >= like
That prevents gems from running if a dependency is newer. For example, rb-launchy is at 3.0.0:
Then I need to do something like this:
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 ` <>` *not* <>; 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.

Precompiled libs is a problem, unfortunately, and some upstream is not interested to bother fixing it.
In result, that is a broken package.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list