This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
bundler attempts to install gems which conflict with an explicit ruby version requirement #6471
Comments
|
In case it matters, I'm really on ruby-2.3.7 and don't have those gems installed for any versions (and couldn't install the versions that its picking up, so it must be getting those from the index): |
|
Also note that rubygems doesn't get this right either: The ohai pin there is because its selecting chef-14, which itself doesn't install on 2.3.x and then picking up the 14.x pin on ohai which blows up. The released version of berkshelf allows This Gemfile solves fine with the manual pin: |
|
So..... I made a release of berkshelf 6.3.2 which pins to The repro case now requires an explict pin onto 6.3.1: |
|
This is happening for me since I'm getting a 429 and Bundler is having to fall back to the gem dependency endpoint |
|
here's my current verbose output if it help someone: |
|
The psych 416 may be the root cause? |
|
I'm not familiar with the endpoints, but it kind of looks like the |
|
Don't see psych as a current dep of berkshelf either in its Gemfile/Gemfile.lock/gemspec |
that's correct
yes, anything that causes bundler to need to fallback to the old dependency API would cause this |
|
@segiddins is there any actions for this issue? |
|
Not really :( |
|
Would it be possible to have the latest gemspec for a gem identify a floor below which versions are deprecated (or some other word which means "too old to consider in clever dependency solutions") and the Alternatively I supposed we could yank all the chef versions before chef 11.0.0 or something, but that makes my eyelid twitch a bit thinking of nuking history like that. Someone out there is also likely happily using chef 0.10.x from 2011 and we'd break them hard... |
Possible? Maybe. Probable? I doubt this would ever get implemented, sorry. In theory, there shouldn't be any issues since bundler caches all of the |
|
This seems answered. |
|
Hi! I come here after reading https://github.com/rspec/rspec/issues/25. Unfortunately the "conclusion" of that thread (as I understand it) is that it's risky for gems to drop support for older rubies, because bundler will continue to try to install the latest version and ignore the This is certainly not true in the great majority of the cases, but it is in this particular case, and I think we could do better. I tried reproducing the issue, and while I couldn't reproduce the 416 error, the installation failed for me due to the I think we could fix that case by falling back to sequentially fetching dependencies from the compact index when this happens instead of doing it in parallel. I tried a proof of concept of this approach and it fixed the issue just fine. Thoughts on this? |
ghost
pushed a commit
that referenced
this issue
Mar 8, 2019
6728: Fallback to sequentially fetching specs on 429s r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem is that sometimes `bundler` is unable to resolve certain gemfiles. Specifically, sometimes it does not respect the `required_ruby_version` setting. This causes some people to assume that `bundler` will always try to install the latest version of any dependency, regardless of the ruby version being run, because as a matter of fact, this feature sometimes just doesn't work. See for example the discussion at https://github.com/rspec/rspec/issues/25. The problem was consistently reproducible until a few minutes ago with the following `Gemfile` under `ruby 2.3.7` ```ruby source "https://rubygems.org" ruby "2.3.7" gem "berkshelf", "= 6.3.1" ``` ``` $ docker run -it --rm --volume $(pwd):/app ruby:2.3.7 sh -c "cd /app && rm -f Gemfile.lock && bundle install" Fetching gem metadata from https://rubygems.org/............. Fetching gem metadata from https://rubygems.org/.. Resolving dependencies.... Fetching public_suffix 3.0.3 Installing public_suffix 3.0.3 Fetching addressable 2.5.2 Installing addressable 2.5.2 Fetching buff-extensions 2.0.0 Installing buff-extensions 2.0.0 Fetching hashie 3.6.0 Installing hashie 3.6.0 Fetching varia_model 0.6.0 Installing varia_model 0.6.0 Fetching buff-config 2.0.0 Installing buff-config 2.0.0 Using bundler 1.16.5 Fetching fuzzyurl 0.9.0 Installing fuzzyurl 0.9.0 Fetching tomlrb 1.2.7 Installing tomlrb 1.2.7 Fetching mixlib-config 2.2.13 Installing mixlib-config 2.2.13 Fetching mixlib-shellout 2.4.0 Installing mixlib-shellout 2.4.0 Fetching chef-config 14.5.33 Installing chef-config 14.5.33 Fetching libyajl2 1.2.0 Installing libyajl2 1.2.0 with native extensions Fetching ffi-yajl 2.3.1 Installing ffi-yajl 2.3.1 with native extensions Fetching mixlib-log 2.0.4 Installing mixlib-log 2.0.4 Fetching rack 2.0.5 Installing rack 2.0.5 Fetching uuidtools 2.1.5 Installing uuidtools 2.1.5 Fetching chef-zero 14.0.6 Installing chef-zero 14.0.6 Gem::RuntimeRequirementNotMetError: chef-zero requires Ruby version >= 2.4.0. The current ruby version is 2.3.0. An error occurred while installing chef-zero (14.0.6), and Bundler cannot continue. Make sure that `gem install chef-zero -v '14.0.6' --source 'https://rubygems.org/'` succeeds before bundling. In Gemfile: berkshelf was resolved to 6.3.1, which depends on chef was resolved to 14.5.33, which depends on chef-zero ``` Funny enough, I can no longer reproduce it at the moment, I guess it depends on the specific load conditions of the rubygems.org servers? ### What was your diagnosis of the problem? My diagnosis was that sometimes our resolution falls back to the old dependency API that didn't implement the `required_ruby_version` setting. In particular, this happens because the new API returns `Net::HTTPTooManyRequests`, so `bundler` gives up and defaults to the old API. ### What is your fix for the problem, implemented in this PR? My fix is to, instead of directly fall back to the old API when rate limiting happens, try first to fetch the dependencies sequentially instead of in parallel still from the new API, so that rate limit does not affect us. ### Why did you choose this fix out of the possible options? I chose this fix because it was the only idea that came up. As a matter of fact, #6471 and #6639 were closed because there was nothing we could do, so it seems like it's the only idea so far :) Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Closed
1 task
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Simple example:
chef-14.0.190 is pinned >= 2.4.0 here:
https://github.com/chef/chef/blob/97c1dd6f1cac6d97e85d05039cad8b28596141ba/chef.gemspec#L16
so chef-14 shouldn't been in the solution set. But it only pins chef-zero to >= 13.0 here:
https://github.com/chef/chef/blob/97c1dd6f1cac6d97e85d05039cad8b28596141ba/chef.gemspec#L35
That itself should have allowed chef-zero 13.x versions which supported 2.3.x to install, but it selected the latest chef-zero-14.x which has been bumped to >= 2.4.0
The text was updated successfully, but these errors were encountered: