Re: Ruby question: solution for dependency version specs?

[Gagan Sidhu via macports-dev]

dear fred,

i understand this is the dev mailing list and politeness does not supersede 
correctness given the topical nature of this mailing list.

i am the last one to be pedantic, but serge *did* qualify his statement with a 
“should” (i.e. expectation), meaning it was not absolute.

let us not be too strong with our correctness and trample the spirit of our 
already-scarce contributors, lest we want them to defect to our snooty 
fink-derived alcohol competitor.

ta ta’

Thanks,
Gagan

P.S/ valerio, you know what’s coming next time you post, so be ready. 
-i didn’t want to scare you off by saying it earlier this week, because 
i was already worried i scared you off the first time!

> On Mar 23, 2024, at 6:59 PM, Fred Wright  wrote:
> 
> 
> On Sun, 17 Mar 2024, Sergio Had wrote:
> 
>> 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.
> 
> Please stop posting falsehoods. Ruby 3.1-3.3 most certainly do *not* work on 
> every system (yet), and I posted a list of the failing cases in another 
> thread where you were a participant.  I haven't looked at 3.4.
> 
>> 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.
> 
> Again, false.
> 
> For at least the past few years, no version of Ruby has worked on all systems 
> until I personally fixed it, and I haven't had a chance to fix anything later 
> than 3.0 yet.  And contrary to popular belief, Ruby 3.0 isn't (quite) EOL yet.
> 
> As far as having multiple versions goes, Ruby is just like many other things, 
> where having multiple versions is useful for (at least):
> 
> 1) Testing code against multiple versions.
> 
> 2) Using a textbook that is based on a particular version.
> 
> 3) Avoiding brokenness in one or more versions.
> 
> No too long ago, the instructions for building the RaspberryPi docs stated 
> that asciidoctor needed to be run with Ruby 2.7 because it didn't work 
> properly with 3.0 (at least for their files).  While that no longer seems to 
> be the case, it does serve to illustrate that newer isn't always better, and 
> that it's best to give users a choice as to what version to use, rather than 
> inflicting someone else's notion of the one true best version on them.
> 
> On Sat, 16 Mar 2024, Austin Ziegler wrote:
> 
>> 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).
> 
> Agreed.  Presumably this came about because having multiple versions wasn't 
> initially anticipated.  It's unfortunate that (unlike some other packaging 
> systems) MacPorts doesn't have a way to directly make multiple versions of 
> something available without resorting to the kludge of building the version 
> number into the name.
> 
> Fred Wright

Re: Ruby question: solution for dependency version specs?

[Fred Wright]

On Sun, 17 Mar 2024, Sergio Had wrote:

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.


Please stop posting falsehoods. Ruby 3.1-3.3 most certainly do *not* work 
on every system (yet), and I posted a list of the failing cases in another 
thread where you were a participant.  I haven't looked at 3.4.


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.


Again, false.

For at least the past few years, no version of Ruby has worked on all 
systems until I personally fixed it, and I haven't had a chance to fix 
anything later than 3.0 yet.  And contrary to popular belief, Ruby 3.0 
isn't (quite) EOL yet.


As far as having multiple versions goes, Ruby is just like many other 
things, where having multiple versions is useful for (at least):


1) Testing code against multiple versions.

2) Using a textbook that is based on a particular version.

3) Avoiding brokenness in one or more versions.

No too long ago, the instructions for building the RaspberryPi docs stated 
that asciidoctor needed to be run with Ruby 2.7 because it didn't work 
properly with 3.0 (at least for their files).  While that no longer seems 
to be the case, it does serve to illustrate that newer isn't always 
better, and that it's best to give users a choice as to what version to 
use, rather than inflicting someone else's notion of the one true best 
version on them.


On Sat, 16 Mar 2024, Austin Ziegler wrote:


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


Agreed.  Presumably this came about because having multiple versions 
wasn't initially anticipated.  It's unfortunate that (unlike some other 
packaging systems) MacPorts doesn't have a way to directly make multiple 
versions of something available without resorting to the kludge of 
building the version number into the name.


Fred Wright

Re: Ruby question: solution for dependency version specs?

[Austin Ziegler]

I will investigate it. I’m in the middle of some *really* busy time at
work, so it will probably be a couple of months (I’ll set myself a reminder
for mid-May, but it’s more likely to be mid-June before I can start), and
it will take some time for me to get up to speed with the Ruby pg and look
at proposing the changes required for it.

-a

On Sat, Mar 16, 2024 at 6:33 PM Sergio Had  wrote:

>
> On Mar 17, 2024, at 6:09 AM, Austin Ziegler  wrote:
>
> 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`.
>
>
> If you could find time to modify Ruby PG to allow this kind of thing, it
> would be great.
>
> At the moment there are simply no tools to allow it, AFAIU.
>
>

-- 
Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Re: Ruby question: solution for dependency version specs?

[Sergio Had]

> On Mar 17, 2024, at 6:09 AM, Austin Ziegler  wrote:
> 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`.

If you could find time to modify Ruby PG to allow this kind of thing, it would 
be great.

At the moment there are simply no tools to allow it, AFAIU.

Re: Ruby question: solution for dependency version specs?

[Austin Ziegler]

On Sat, Mar 16, 2024 at 3:29 PM Sergio Had  wrote:

> On Mar 17, 2024, at 12:57 AM, Austin Ziegler  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 • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Re: Ruby question: solution for dependency version specs?

[Sergio Had]

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

Re: 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  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 • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Ruby question: solution for dependency version specs?

[Sergio Had]

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.