Ruby question: solution for dependency version specs?

[Gagan Sidhu]

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 <fw at fwright.net> 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

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