Ruby question: solution for dependency version specs?

[Austin Ziegler]

On Sat, Mar 16, 2024 at 3:29 PM Sergio Had <vital.had at gmail.com> wrote:

> 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.
>

I could, but I think you misunderstand: as someone who has done a lot of
Ruby development and have responsibility for a couple of 100M+ downloaded
gems (both mime-types and diff-lcs are mine), I *choose* not to use system
Ruby installations, including those of MacPorts. Much of it has to do with
why systems like chruby, rbenv, and rvm exist — Debian maintainers made an
absolute hash of Ruby packaging in the early 2000s and often frequently did
a poor job of packaging the few gems that they did.

> 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.
>

While not all Ruby gems follow strong semver, what you are doing here is
inadvisable at best. Ruby *permits* (through RubyGems) the installation of
multiple versions of the same gems—and as Ruby versions are released, more
of the standard library is being shifted into "default gems", meaning that
applications can choose to use later versions that may have new features or
possible bug fixes that are not included in the shipped version of Ruby.

Ruby packages would be much better served by installing gems *as gems*
(this can be done offline with `gem install --local foo-version.gem` once
downloaded) than trying to repackage all of the gems as ports with only a
single version available. I have (extremely vague) plans at some point for
mime-types 4 and diff-lcs 2 that will drop support for any version of Ruby
less than 3.0, but that will not stop mime-types 3 and diff-lcs 1 from
working on older versions of Ruby.

I reiterate that Ruby application ports (like sup or t) should *probably*
be set up more like Go or Rust ports and that a tool like `go2port` or
`cargo2port` (`gemspec2port, bundler2port`) which ultimately downloads the
gemfiles and uses `gem install --local …` will be better than blindly
modifying the *intentional* use of `~> 3.0` or installing `rb33-launch 3.0`.

-a
-- 
Austin Ziegler • halostatue at gmail.com • austin at halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20240316/3081c5dc/attachment-0001.htm>