Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

Bundler doesn't respect bundle update --source ... when gem and git repo differ in name #3761

Closed
neoeno opened this issue Jun 18, 2015 · 3 comments

Comments

@neoeno
Copy link
Contributor

neoeno commented Jun 18, 2015

This is related to and explained by #3759.

Let's say I have a Gemfile

source 'https://rubygems.org'
gem 'rubocop', github: 'neoeno/rubocop_renamed'

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:

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 in any of the sources

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

@richbowen
Copy link

I can reproduce this issue with the Gemfiile.lock provided in the bundle_test repository, however, when I delete that Gemfile.lock and run bundle update --source rubocop_renamed, it works fine updating rubocop to version 0.32.0.2.

When did you clone the rubocop repository? It could be that because you cloned after the revision: 2c669b384421bb163aa6a58b045d2eb256ef295b and also renamed your clone of the repository to rubocop_renamed, it is causing this issue with rubocop-0.32.0 not being found because it is looking for a point where, in the rubocop_renamed repository, that specific commit was made which doesn't not exist. This is just an assumption.

@neoeno
Copy link
Contributor Author

neoeno commented Jun 18, 2015

That's a valid possibility — worth investigating. Here's what I did to investigate:

I pulled down the repository, then the following:

  1. bundle update
  2. Pushed a new version bump commit to rubocop_renamed (https://github.com/neoeno/rubocop_renamed/commit/2bf754be48cdeddad6d66585bec689a3e235ea2b)
  3. bundle update --source rubocop_renamed

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?

homu added a commit that referenced this issue Aug 24, 2015
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.
@agis
Copy link
Contributor

agis commented Oct 22, 2015

Fixed by #3763.

@agis agis closed this as completed Oct 22, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants