Ruby question: solution for dependency version specs?

[Austin Ziegler]

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

I have *not* looked at the Ruby pg or many of the Ruby ports themselves,
but Ruby has a very high level of backwards compatibility, at least for
pure Ruby gems (no C extensions):

- Code written for Ruby 1.6 or higher *may* run unmodified on later
versions, including Ruby 3.3. If there is string manipulation at the
character level, from Ruby 1.9 the string representation changed from just
a bag of bytes to a bag of bytes with an encoding attached so that direct
character access does not give the byte at that position.
- Code written for Ruby 1.9 or higher will *most likely* run unmodified on
later versions, including Ruby 3.3, excepting about 4–5 methods that were
deprecated in Ruby 2.0–2.4 and finally removed in Ruby 3.3.

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

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

*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` *not* github.com; gems are source
distributions most of the time, although some gems exist that contain
precompiled binaries for hard-to-build dependencies).

-a

On Sat, Mar 16, 2024 at 10:52 AM Sergio Had <vital.had at gmail.com> wrote:

> Any Ruby experts among us?
>
> Some Ruby ports hardcode versions for dependencies in a form restricting
> those to a given major or minor version. Since many Ruby gems are not
> updated for years (but still required for other stuff), this presents a
> problem: any dependency using those will build but not run.
> Is there a way to solve this other than by patching every such instance?
> Patching works but is pretty tedious.
> Ideally a solution via Ruby PG is preferred, I think.
>


-- 
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/80e4f35a/attachment.htm>