Allow to ignore "required_ruby_version" requirement

[mame]

What was the end-user or developer problem that led to this PR?

Unfortunately, some gems have a requirement like:

s.required_ruby_version = "~> 2.4"

In fact, this is somewhat non-sense because Ruby version is not the
semantic versioning: so there are some incompatibilities even in minor
release. Allowing Ruby 2.7 but denying 3.0 does not make sense.
Worse, this makes it difficult to try Ruby 3.0 in the real-world
applications.

What is your fix for the problem, implemented in this PR?

This changeset allows a user to ignore the "required_ruby_version"
requirement by manually specifying an environment called
RUBYGEMS_IGNORE_RUBY_VERSION_REQUIREMENT.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[deivid-rodriguez]

I'm 👎 on this.

I don't want to maintain this code. After this, someone wants an environment variable to ignore dependency constraints for all gems, then for a single gem, then to only relax them but not ignore them, then to also ignore rubygems constraints... I don't want to open the door for this since in my opinion it's an unhealthy change.

In my view, supporting this discourages people from doing the right thing: reaching out to the gem that's at fault, explaining the rationale for changing the gemspec and proposing the change upstream. If you're ignored or you are in a hurry, we already provide tools for temporarily forking gems and pointing to your own fork.

To try a gem against 3.0 that does not currently support it, one should fork the gem, change the required_ruby_version constraint in the gemspec, and open a PR to get CI run for the gem. That way you can try the gem against ruby 3.0, and in addition to that, you have already started the path for actually adding support for ruby 3.0, and made the gem author aware of an issue with her gem.

[mame]

I respect your decision. But let me say my opinion.

I think that ~> X.X was a wrong invention. I have seen forking a gem just to avoid ~> X.X requirement so many times. Honestly, I feel a waste of time. I can't believe that it is "doing the right thing".

I want all gems to be optimistic against future incompatibility. Only when a gem author knows that their gem is actually not compatibile with the new version of a dependency, they should use < X.X requirement more explicitly.

If bundler is truly pessimistic, "Minimal Version Selection" mode that golang uses looks a more reasonable approach to me.

Anyway, I believe that it is a right thing to allow an end user to be optimistic. Especially, w.r.t. Ruby version, ~> X.X requiement makes no sense.

[simi]

I do understand your concern @mame, anyway there's really nothing we can do about. AFAIK majority of gems are bootstrapped by bundle gem template and there was no default option unless recently introduced >= 2.3.0 constraint.

ff7cc37#diff-bdf7b5b2a62792f72623e19ef3b663826eb0a4e214eee8103eb0ce24849e4e69R15

Any usage of ~> operator for ruby requirement is just decision of gem author we should respect even it doesn't make really sense with Ruby versioning scheme.

According to your problem with testing real-world apps and by-passing this requirement. Wouldn't be enough to fake RUBY_VERSION?

[retro@retro  rubygems (master %=)]❤ ruby -v
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]
[retro@retro  rubygems (master %=)]❤ cat fakeruby.rb 
RUBY_VERSION='2.5.3'
[retro@retro  rubygems (master %=)]❤ ruby -I. -rfakeruby.rb -S gem env | grep RUBY
/home/retro/code/work/oss/rubygems/fakeruby.rb:1: warning: already initialized constant RUBY_VERSION
  - RUBYGEMS VERSION: 3.1.4
  - RUBY VERSION: 2.5.3 (2020-10-01 patchlevel 137) [x86_64-linux]
  - RUBY EXECUTABLE: /home/retro/.rubies/ruby-2.7.2/bin/ruby
  - RUBYGEMS PLATFORMS:
[retro@retro  rubygems (master %=)]❤ ruby -I. -rfakeruby.rb -e 'puts Gem.ruby_version'
/home/retro/code/work/oss/rubygems/fakeruby.rb:1: warning: already initialized constant RUBY_VERSION
2.5.3.137

[deivid-rodriguez]

@mame I agree with you and personally prefer >= for required_ruby_version. We do generate a default s.required_ruby_version = ">= <minimal_ruby_version>" constraint for new gems generated with bundler.

But IMO the best way to change this for existing gems is to properly explain the rationale to gem authors that are actually doing this, not to override bundler's and rubygems behaviour without the gem author noticing. After all, once you try this and verify it works, the gem author is going to need to change the gemspec to make support generally available anyways. Isn't that a great opportunity to motivate a change to their required_ruby_version strategy and remove the ~> in favour of only a lower bound?

If you're not proposing this as a stop gap until gems add support, but as a permanent solution, then it seems like the wrong approach to me. The correct approach would be to completely forbid ~> inside the required_ruby_version field, not to silently replace it with >= That's a different story that could be considered, but would require consensus, a deprecation path, proper communication and so on. And honestly, I'm also against that, seems too much trouble for little benefit.

[hsbt]

I understood @mame's opinion because I always frustrated the ruby version restriction of dependencies for my work in January.

I also agree @deivid-rodriguez 's opinion. We should avoid the environmental variable approach. So, I have no idea to avoid this restriction smarty.

[ioquatix]

I think that gems need to be updated. I can't see any other reasonable solution.

[deivid-rodriguez]

We're not really convinced that we want to introduce something like this at all, but if we were to introduce it, we prefer the proposal at #4178, so I'm closing this.

Thanks for taking the time to raise this issue though, @mame.