This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
Falling back to the dependency API on 1.14 #5373
Labels
Comments
|
I am unable to reproduce this -- can you please share the output of |
|
Issue was initially encountered on a server running Amazon Linux, but I can also reproduce locally on OS X 10.12.2 using the system ruby. Output below is from the Linux box.
EnvironmentGemfile.lock
|
|
Issue is that bundler is hitting the dependency API for some reason instead of the new index (which is the only one of the ways of fetching dependencies that actually contains the |
segiddins
changed the title
|
Reverting the change to lib/bundler/definition.rb from c8149f7 fixes the issue for me locally |
|
Can you share the output with that commit reverted with |
|
@segiddins having trouble reproducing the issue once I've had the bundle install successfully. Tried uninstalling off the gems bundler installed and removing Gemfile.lock. Is there a cache somewhere I need to delete? |
|
Not for the dependency API, no |
|
Tried the modified gem on the server, and it doesn't fix the issue there. Not sure what was going on in my local environment. |
|
ping @jschnurholmes is this still an issue? |
|
I've seen this issue more recently, but I didn't notice what version of bundler I was running at the time. |
|
I reproduced, too in |
|
@tsuwatch please share the output of |
|
|
Ah! |
|
Oh, I see. |
bundlerbot
added a commit
that referenced
this issue
Jul 8, 2017
Avoid Range Not Satisfiable errors during normal request flow ### What was the end-user problem that led to this PR? Previously, Bundler was requesting partial response ranges for the Rubygems compact index that could be empty. Since Rubygems was [ignoring the `ETag` header](rubygems/rubygems.org#1652) for these requests, empty ranges would occur whenever the versions index (for instance) hadn't been modified since the version Bundler currently had cached. When this happened, Rubygems would respond with a 416 (Range Not Satisfiable). Bundler would treat this as a `Bundler::HTTPError`, and fall back to using `Fetcher::Dependency` for dependency info. Sadly, that meant metadata about what Ruby version each dependency required was no-longer checked, and updates for gems which should be limited by the system Ruby version were failing. Closes #5373. ### What was your diagnosis of the problem? See above ### What is your fix for the problem, implemented in this PR? This PR updates the range Bundler requests from Rubygems to ensure it's always satisfiable. It does that but requesting all bytes from (and including) the final byte in the Bundler cache, rather than all bytes after (and not including) it. ### Why did you choose this fix out of the possible options? An alternative fix would be to catch the 416 responses and retry the index lookup in those cases, asking for a full response. That would mean an extra request in all of those cases, though - this method keeps the number of calls to Rubygems down.
segiddins
pushed a commit
that referenced
this issue
Jul 17, 2017
Avoid Range Not Satisfiable errors during normal request flow ### What was the end-user problem that led to this PR? Previously, Bundler was requesting partial response ranges for the Rubygems compact index that could be empty. Since Rubygems was [ignoring the `ETag` header](rubygems/rubygems.org#1652) for these requests, empty ranges would occur whenever the versions index (for instance) hadn't been modified since the version Bundler currently had cached. When this happened, Rubygems would respond with a 416 (Range Not Satisfiable). Bundler would treat this as a `Bundler::HTTPError`, and fall back to using `Fetcher::Dependency` for dependency info. Sadly, that meant metadata about what Ruby version each dependency required was no-longer checked, and updates for gems which should be limited by the system Ruby version were failing. Closes #5373. ### What was your diagnosis of the problem? See above ### What is your fix for the problem, implemented in this PR? This PR updates the range Bundler requests from Rubygems to ensure it's always satisfiable. It does that but requesting all bytes from (and including) the final byte in the Bundler cache, rather than all bytes after (and not including) it. ### Why did you choose this fix out of the possible options? An alternative fix would be to catch the 416 responses and retry the index lookup in those cases, asking for a full response. That would mean an extra request in all of those cases, though - this method keeps the number of calls to Rubygems down. (cherry picked from commit 288b3c9)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Specifying a ruby version in the Gemfile no longer causes bundler to find versions of gems compatible with the specified ruby version.
Gemfile used for testing:
output of
ruby -vruby 2.0.0p648 (2015-12-16) [x86_64-linux]output of
bundle install:Tested with bundler version 1.14.0, 1.14.1, 1.14.2, 1.14.3. Command works on bundler v 1.13.7
The text was updated successfully, but these errors were encountered: