Bundler should try to resolve using the private source for my-private-gem and all of its indirect dependencies. Only if a valid resolution is not found, it should also consider rubygems.org for those dependencies.
Insted, Bundle will still install my-another-private-gem from rubygems.org if the gem exists there. We should probably search first in the same source as my-private-gem before falling back.
For implicit gems (dependencies of explicit gems), any source, git, or path repository declared on the parent. This results in bundler prioritizing the ActiveSupport gem from the Rails git repository over ones from rubygems.org
which is the expected behavior as per the issue but not observed.
#4609 should fix this and make bundler behave as documented.
Note that the solution slightly differs from what I originally proposed in the sense that if a scoped source includes any version of my-private-gem, the gem will be picked up from there. Falling back to the default source would only happen if the name does not exist at all in the scoped source.
As I originally proposed it, the fallback would also happen if the scoped source includes my-private-gem but not a version that matches all requirements. With this solution, bundler will fail to resolve claiming that it couldn't find a compatible version of my-private-gem in https://my-private-server. I can't make the original proposal work since my approach is to resolve sources for each involved gem name beforehand before resolution even starts.
I think this solution matches the documentation exactly, and it's what users intuitively expect, so seems fine to me.
In a situation like the following:
Bundler should try to resolve using the private source for my-private-gem and all of its indirect dependencies. Only if a valid resolution is not found, it should also consider
rubygems.orgfor those dependencies.
Insted, Bundle will still install
my-another-private-gemfrom rubygems.org if the gem exists there. We should probably search first in the same source as
my-private-gembefore falling back.
Originally posted by @rafaelfranca in #3948 (comment)
The text was updated successfully, but these errors were encountered: