rb-netrc and friends: update to current versions, support modern Ruby

[barracuda156]

Description

This port can be updated to the latest version, since minimum required is 0: https://rubygems.org/gems/netrc
There is also zero reason to restrict it to Ruby 1.9.

(I guess, there is no point to add all the zoo of Ruby versions; I keep archaic ones since many Ruby ports in Macports still use those, and add modern ones.)

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 14.2.1
Xcode 15.2

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?
• checked your Portfile with port lint --nitpick?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[pmetzger]

I don't think a lot of maintenance has happened for the Ruby ports of late. We should probably be clearing out the ancient stuff that is way out of support to the greatest extent possible.

[barracuda156]

@pmetzger To be honest I have no objections to removing anything earlier than Ruby 3.1, and surely all 1.x stuff. That will make updating Ruby stuff far easier.
However some of those ports are maintained, at least nominally, by @kimuraw and maybe somebody else. So it is not up to me to decide.

There might be some sense in retaining archaic Ruby for the sake of Tiger (ppc and x86), but Tiger is not something I care about personally, so I do not insist on maintaining it. (10.5–10.6 on PowerPC should work with the latest Ruby 3.1+.)

[barracuda156]

@pmetzger Here however there is no complication to have older Ruby supported – we need ruby.branches here anyway. I do not think this is a relevant problem with this specific port, since everything is the same.

[barracuda156]

@pmetzger I was going to update several Ruby ports once these PRs are merged; if there is a consensus not to keep 1.x Ruby support (which I am okay with), I remove it with updates. Otherwise I can make all related updates preserving existing versions for Ruby 1.x. (I am not gonna bother determining which was the latest version to work with each old Ruby, but keeping what we already have is no problem.)

[pmetzger]

So we've had a policy, for support and security reasons, of doing things like getting rid of truly ancient versions of Python. This isn't that different a situation.

[barracuda156]

@pmetzger Okay, no issues with this from my side. I can move to new Ruby with upcoming updates and drop old ones. I may need to add a bit more into this PR to do it coherently without breaking some dependent.

[pmetzger]

I suppose it depends on the question of how much stuff is dependent on old versions of Ruby. 1.8 and 1.9 are truly ancient at this point btw.

[barracuda156]

I suppose it depends on the question of how much stuff is dependent on old versions of Ruby. 1.8 and 1.9 are truly ancient at this point btw.

@pmetzger Well, most of Macports Ruby stuff or it least a large part of it at the moment is for archaic Ruby.
I am fine with keeping what is there at the moment, I can add support for new Ruby with current versions of gems without breaking anything for archaic Ruby.
Alternatively, I can keep removing archaic versions in chunks, by dependency tree.
I am mostly indifferent here, though removing support for old versions is a bit easier burden-wise and results in much simpler portfiles. At the same time, it is not a huge extra work to retain old versions of gems for old Ruby.

So you tell me which is better. Let us just do it some way, since the stuff is stuck unupdated for ages. We certainly do not want to have only archaic Ruby supported :)

[pmetzger]

I don't know what's best. Someone on -dev may have an opinion.

[barracuda156]

To be honest, it is ridiculous that Macports has a Ruby port which installs some pre-historic version. Even TigerBrew uses 2.x.

IMO, it should follow Python model. No unversioned ports in general, get rid of the zoo of outdated and conflicting (!) versions, bring all existing Ruby ports to support 3.1+, perhaps dump everything earlier.

There are arguably no reasons to have 1.8 and 1.9 both even for a sake of compatibility, since the earliest system we support, Tiger, should work with Ruby 2.4 and definitely with 1.9.

[halostatue]

As a Rubyist, I would generally agree, although I would keep Ruby 2.7 for another year or so, even though it is EOL. (I don't generally pay attention to MacPorts Ruby since I use ruby-build in one form or another to install the Ruby versions that I need.)

[barracuda156]

@halostatue We do not need to remove versioned rubyX lang ports, they do not pose any problem. What does pose a problem is a multitude of mostly unversioned and very outdated ruby gems.
So yes, we can surely keep 2.7 (and I would say 2.4 for Tiger).

[kimuraw]

I suppose it depends on the question of how much stuff is dependent on old versions of Ruby. 1.8 and 1.9 are truly ancient at this point btw.

rubygems was born at last of ruby-1.8/1.9 versions.
before rubygems, we installed ruby libraries with some scripts called "install.rb" or "setup.rb".

like this:

1. download tarball and extract
2. run ruby install.rb or ruby setup.rb && make && make install

[barracuda156]

@kimuraw What would you prefer, just moving to new Ruby (and dropping 1.8/1.9 ports) or retaining existing old versions for compatibility and adding modern ones along with those?

[pmetzger]

So we typically have ports of packages in Perl and Python and other scripting languages for two purposes: (1) because someone wants the thing in itself and (2) because some other port depends on something. To the extent that little or nothing is in (2) and is dependent on something old, we have a great deal of freedom to simply update anything in category (1). That is to say, if little or nothing actually demands that we use some old crusty Ruby 1.8 thing, then we can drop it or replace it with the modern form.

[barracuda156]

@halostatue On a side note – the question is not immediately related to this PR – could you say what can be done about this sort of errors?

svacchanda@43-95 ~ % /opt/local/libexec/ruby3.3/t
/opt/local/lib/ruby3.3/3.3.0/rubygems/specification.rb:1484:in `rescue in block in activate_dependencies': Could not find 'oauth' (~> 0.5.1) among 124 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/Users/svacchanda/.local/share/gem/ruby/3.3.0:/opt/local/lib/ruby3.3/gems/3.3.0' at: /opt/local/lib/ruby3.3/gems/3.3.0/specifications/t-4.0.0.gemspec, execute `gem env` for more information
	from /opt/local/lib/ruby3.3/3.3.0/rubygems/specification.rb:1481:in `block in activate_dependencies'
	from /opt/local/lib/ruby3.3/3.3.0/rubygems/specification.rb:1470:in `each'
	from /opt/local/lib/ruby3.3/3.3.0/rubygems/specification.rb:1470:in `activate_dependencies'
	from /opt/local/lib/ruby3.3/3.3.0/rubygems/specification.rb:1452:in `activate'
	from /opt/local/lib/ruby3.3/3.3.0/rubygems.rb:280:in `block in activate_bin_path'
	from /opt/local/lib/ruby3.3/3.3.0/rubygems.rb:279:in `synchronize'
	from /opt/local/lib/ruby3.3/3.3.0/rubygems.rb:279:in `activate_bin_path'
	from /opt/local/libexec/ruby3.3/t:25:in `<main>'
/opt/local/lib/ruby3.3/3.3.0/rubygems/dependency.rb:315:in `to_specs': Could not find 'oauth' (~> 0.5.1) - did find: [oauth-1.1.0] (Gem::MissingSpecVersionError)

I was gonna add some new packages, everything installs fine, but then I keep getting these silly errors with mismatching versions.
All packages are installed from rubygems via portfiles, no patching from my side, everything seems to be standard and identical to how it is done in existing ports.

And needed dependencies are installed, but for some reason Ruby cannot acknowledge these are acceptable versions.

[halostatue]

@barracuda156 Not offhand; I haven't used system-installed Rubies in a long time (and MacPorts would be one, even though it's not Apple native). I would need some more context on how you got to this point.

However, RubyGems allows multiple simultaneous installations of different versions of gems, which is not natively supported by MacPorts (well, simultaneous installations are allowed, but not simultaneous activations). For MacPorts to properly manage RubyGems installations, we would need something like ten packages (rb{27,30,31,32,33}-oauth-{0.5.1,1.1.0}) just for the Ruby variations from 2.7–3.3 for these two versions of the oauth gem. Which is to say that there's an impedance mismatch between MacPorts and Ruby for this. It's not that it's not possible to do, but that there would have to be an entirely different approach, I think…and I don't have a clue what it should be.

[kimuraw]

@kimuraw What would you prefer, just moving to new Ruby (and dropping 1.8/1.9 ports) or retaining existing old versions for compatibility and adding modern ones along with those?

@barracuda156 I prefer former.

but I wonder most of rb18|19 ports not work with recent versions of ruby.
then I remove those ports from macports.

[barracuda156]

@kimuraw What would you prefer, just moving to new Ruby (and dropping 1.8/1.9 ports) or retaining existing old versions for compatibility and adding modern ones along with those?

@barracuda156 I prefer former.

but I wonder most of rb18|19 ports not work with recent versions of ruby. then I remove those ports from macports.

@kimuraw Got it, thank you. Then we can just update those for which modern versions are available.

[barracuda156]

@kimuraw Let’s see if this works. Hopefully all dependents are taken care of, but if something missed, I will add that.

[reneeotten]

what's the status of this - anyone interested in finishing this off?

[barracuda156]

@reneeotten I will give it another go, yeah. While I don’t hold this important, this Ruby cleanup needs to be done, and not having it done prevents from adding anything useful for Ruby.

[barracuda156]

Still fails.

@pmetzger Well, I know, because turned out that a tarball of rb-heroku is broken on Rubygems now, and fails to install.
(Don’t ask me how I installed it earlier, I wiped everything ruby-ish to start from scratch and be able to reproduce failures of CI locally.)

It might build now, let’s see.

[barracuda156]

UPD. Mostly, but not yet. Will finish this soon anyway. But I kinda get now why nobody wanted to touch Ruby stuff :)

[halostatue]

@barracuda156 If you want, you can add me ({macports.halostatue.ca:austin @halostatue}) as maintainer for rb-mime-types and rb-mime-types-data with openmaintainer instead of nomaintainer. I should be able to update those whenever I release new versions of mime-types and mime-types-data.

[barracuda156]

@halostatue Awesome, sure, will do now.

[barracuda156]

@pmetzger Are we good with this one?

[pmetzger]

I'm not sure everything is perfect but things seem strictly better. Note that there is a stupid lint warning for rb-multi_json; I'd appreciate if you fixed it in a subsequent commit.

[barracuda156]

@pmetzger Thank you for pointing, I will look into that lint issue.

I will probably do some Ruby-related PR in a week or two: while I will be away from PowerPC machines, I do not need to test Ruby stuff there. (It will probably work on ppc, or if not, it is isolated and can be fixed later.)