-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Bundler doesn't respect bundle update --source ...
when gem and git repo differ in name
#3761
Comments
I can reproduce this issue with the When did you clone the rubocop repository? It could be that because you cloned after the |
That's a valid possibility — worth investigating. Here's what I did to investigate: I pulled down the repository, then the following:
Log: $ bundle update
Updating git://github.com/neoeno/rubocop_renamed.git
Fetching gem metadata from https://rubygems.org/.........
Fetching version metadata from https://rubygems.org/..
Resolving dependencies...
Using ast 2.0.0
Using parser 2.2.2.5
Using astrolabe 1.3.0
Using powerpack 0.1.1
Using rainbow 2.0.0
Using ruby-progressbar 1.7.5
Using rubocop 0.32.0.2 (was 0.32.0) from git://github.com/neoeno/rubocop_renamed.git (at master)
Using bundler 1.10.4
Bundle updated!
$ bundle update --source rubocop_renamed
Updating git://github.com/neoeno/rubocop_renamed.git
Fetching gem metadata from https://rubygems.org/.........
Fetching version metadata from https://rubygems.org/..
Resolving dependencies...
Could not find rubocop-0.32.0.2 in any of the sources Which would suggest to me that it's not to do with the renaming of the repository. Does that seem like an accurate deduction to you? |
Fix `--source` option causing incorrect gem unlocking Fixes #3759 and #3761. And also another issue I found where if: 1. You have a Gemfile with a group, 2. That group contains a gem with the same name as a source 3. And you run `bundle update --group group_name` 4. Then all gems associated with the source will be updated. The 3 cases fixed here are all pretty subtle. The specs should make it clearer, and the github issues above add more context. Note that this PR removes the ability to use `bundle update --source gem_name` as a hacky way to update a gem 'conservatively'. This is detailed in #3759.
Fixed by #3763. |
This is related to and explained by #3759.
Let's say I have a Gemfile
And I've got a previously generated Gemfile.lock.
But the repository has just been updated, so I run:
$ bundle update --source rubocop_renamed # Look here for how the source name is inferred: https://github.com/bundler/bundler/blob/master/lib/bundler/source/git.rb#L76-L78
I get the following output:
Since I'm updating the source, I'd expect the source and all its gems to be unlocked and thereby updated.
There's an example in http://github.com/neoeno/bundle_test
The text was updated successfully, but these errors were encountered: