Lock gems that fail to install on certain Ruby versions

[pirj]

Bundler fails to install several gems. It seems that Ruby version constraint is ignored.

E.g. Sprockets 4.0 depend on Ruby >= 2.5 https://rubygems.org/gems/sprockets/versions/4.0.0
This results in build failures (https://travis-ci.org/github/rspec/rspec-rails/jobs/713253057):

Installing sprockets 4.0.2
Gem::RuntimeRequirementNotMetError: sprockets requires Ruby version >= 2.5.0.
The current ruby version is 2.4.10.364.

Surprisingly, Ruby 2.3.8 and Ruby 2.2.10 builds don't fail, and install sprockets 3.7.2.

This is a forgotten forward-port from https://github.com/rspec/rspec-rails/pull/2360/files#diff-8c3955be04b733dbd31e54e50844fb84R31

[pirj]

It's like a house of cards.

Fetching capybara 3.33.0
Installing capybara 3.33.0

Gem::RuntimeRequirementNotMetError: capybara requires Ruby version >= 2.5.0. The current ruby version is 2.4.10.364.

An error occurred while installing capybara (3.33.0), and Bundler cannot continue.

Make sure that `gem install capybara -v '3.33.0' --source 'https://rubygems.org/'` succeeds before bundling.

It also happens quite randomly. This time Ruby 2.4 build broke, but not 2.3 nor 2.2.

Another thing that I've noticed is that Ruby version constraints for some gems differ when you check them on https://rubygems.org/gems//versions/ and then you check it with gem specification --remote <gem> --version <version>. Don't have any example handy, but pretty sure I can find it.

Any newly released gem with a Ruby version constraint can break our build. Do you think those problems are worth Bundler core team attention?

[pirj]

Builds are green. I'm going to delete all repository caches, squash the commits and see if the builds are still green.

[JonRowe]

Leave this, we're still soft supporting 4.2 and this makes it tricky to properly install locally.

[JonRowe]

👍 Merge on green.

[benoittgt]

Do you think those problems are worth Bundler core team attention?

Maybe @deivid-rodriguez have an idea? 🙂

[pirj]

This is green, but the question still remains.
@deivid-rodriguez can you suggest what we are doing wrong here?
We run several build jobs, each for a different Ruby/Rails combination. The Gemfile we provide, doesn't specify a version of e.g. i18n, rack, childprocess, capybara to use, it's what we rely on from Rails' Gemfile. On Ruby 2.4 and RAILS_VERSION='~> 5.0.0' (resolved to 5.0.7.2), bundler attempts to install sprockets version 4.0.2 for some reason:

Installing sprockets 4.0.2

Gem::RuntimeRequirementNotMetError: sprockets requires Ruby version >= 2.5.0. The current ruby version is 2.4.10.364.
An error occurred while installing sprockets (4.0.2), and Bundler cannot continue.
Make sure that `gem install sprockets -v '4.0.2' --source 'https://rubygems.org/'` succeeds before bundling.

In Gemfile:

  rails was resolved to 5.0.7.2, which depends on
    sprockets-rails was resolved to 3.2.1, which depends on
      sprockets

rake aborted!

sprocket-rails 3.2.1 depend on sprockets >= 3.0.0, and sprockets 3.7.2 depend on Ruby >= 1.9.3 - I don't understand why it attempts to install 4.0.2:

$ gem specification --remote sprockets --version 4.0.2
...
required_ruby_version: !ruby/object:Gem::Requirement
  requirements:
  - - ">="
    - !ruby/object:Gem::Version
      version: 2.5.0

$ gem specification --remote sprockets --version 3.7.2
...
required_ruby_version: !ruby/object:Gem::Requirement
  requirements:
  - - ">="
    - !ruby/object:Gem::Version
      version: 1.9.3

Question: Is it Bundler that is unable to reduce the dependency considering the Ruby version constraint? Or should we look into what Travis' intermediate gem server is providing us with broken gem metadata?

The following versions of RubyGems/Bundler are used:

Bundler 2.1.4 installed
RubyGems 3.1.4 installed

[deivid-rodriguez]

Hi! Thanks for letting me know.

This is indeed an issue with bundler. A long time ago, bundler used a dependency API that didn't have required_ruby_version information. These days bundler uses a better API that does provide required_ruby_version information. However, under some circumstances, specifically, when the client is rate limited by rubygems.org because of too many concurrent requests, we still end up falling back to using the old API, causing this kind of intermittent problems.

I think we had relaxed the limits on the server side to minimize these issues, but the right fix is that bundler completely stops using the old API and instead waits a bit before retrying the new API again when being rate limited. This fix is being tracked at rubygems/rubygems#3594.

[pirj]

Thanks a lot @deivid-rodriguez, this makes total sense!

[deivid-rodriguez]

No problem, and apologies for the trouble. We'll try to fix this.

[benoittgt]

Ooooh good to know! Thank you very much!

…

On August 1, 2020 12:16:15 PM GMT+02:00, "David Rodríguez" ***@***.***> wrote: Hi! Thanks for letting me know. This is indeed an issue with `bundler`. A long time ago, bundler used a dependency API that didn't have `required_ruby_version` information. These days bundler uses a better API that _does_ provide `required_ruby_version` information. However, under some circumstances, specifically, when the client is rate limited by rubygems.org because of too many concurrent requests, we still end up falling back to using the old API, causing this kind of intermittent problems. I think we had relaxed the limits on the server side to minimize these issues, but the right fix is that `bundler` completely stops using the old API and instead waits a bit before retrying the new API again when being rate limited. This fix is being tracked at rubygems/rubygems#3594. -- You are receiving this because your review was requested. Reply to this email directly or view it on GitHub: #2366 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[deivid-rodriguez]

Hei! Discussing this internally, this might actually not be due to rate limiting but to a different error condition. Bundler should log the exception that's causing the fallback to the old API in --verbose mode here, I believe. If you could use the --verbose flag and report back when this happens again, that would give us more information about this.

[pirj]

@deivid-rodriguez Awesome!
Got some results (1, 2) already for a PR specifically open to reproduce the failure. Please let me know if this is sufficient to pinpoint the issue.

Just to confirm that we're still experiencing the issue there's a similar failure from another build for a branch where:

if RUBY_VERSION < "2.3.0"
    gem 'i18n', '< 1.5.2'

is supposedly set, and the failure is:

Gem::RuntimeRequirementNotMetError: i18n requires Ruby version >= 2.3.0. The current ruby version is 2.2.0.
An error occurred while installing i18n (1.8.5), and Bundler cannot continue.

[pirj]

@deivid-rodriguez Ping. Is this of any help?
No pressure, we're in pretty good shape in terms of build stability right now. At the cost, though.
For me, it will be good enough if you are aware of the problem, there's a ticket, and it will eventually be resolved so we can clean our build-related dependency declaration code.

[pirj]

@deivid-rodriguez Ping. Can I provide anything else to help to pinpoint the issue?

[pirj]

@deivid-rodriguez Ping.

[deivid-rodriguez]

Hi @pirj, sorry for the delay, I was on holidays and for the first time in years I succeeded on fully disconnecting 😅.

Your logs are super useful, they show a Net::OpenTimeout error. We've had some long standing issues with DNS resolution being very slow when connecting to rubygems.org over ipv6. I guess this might be another instance of the same issue. @sonalkr132 was dedicating efforts on improving this situation, maybe he has some feedback.

In any case, I'm catching up with stuff now, but this is definitely a priority for me once I'm done with the catching up 👍.

[pirj]

@deivid-rodriguez no worries, I was only afraid this will slip through the cracks. Not rushing in any way. It's actually a great achievement, I admire it. Also jealous knowing that I won't able to fight the temptation to at least check and reply to mail during my upcoming vacation.

Great! Just let me know if you need any additional information. Again, no rush, and no pressure. Thanks for taking care of that.

[deivid-rodriguez]

@deivid-rodriguez no worries, I was only afraid this will slip through the cracks. Not rushing in any way. It's actually a great achievement, I admire it. Also jealous knowing that I won't able to fight the temptation to at least check and reply to mail during my upcoming vacation.

I used a trick that turned out to be very effective: I left my laptop and passwords at home, to completely eliminate the temptation 😄

Great! Just let me know if you need any additional information. Again, no rush, and no pressure. Thanks for taking care of that.

I will keep you posted!

[sonalkr132]

Gem::RuntimeRequirementNotMetError: i18n requires Ruby version >= 2.3.0. The current ruby version is 2.2.0.
An error occurred while installing i18n (1.8.5), and Bundler cannot continue.

This should no longer be an issue. I ran build on the same commit and it is passing https://travis-ci.com/github/sonalkr132/rspec-rails/jobs/379918197

they show a Net::OpenTimeout error.

this was probably an intermittent error and bundler continued with retry.
we backfilled required_ruby_version on older versions (16-17 Aug) after you reported rubygems/rubygems#3870 which would have fixed the mismatch in the required ruby version.

[deivid-rodriguez]

Oh, right! This was fixed by backfilling those, I forgot about it!