Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Global vs block gem server source priority doesn't work as expected #3982

Closed
deivid-rodriguez opened this issue Sep 30, 2020 · 2 comments · Fixed by #3655 or #4609
Closed

Global vs block gem server source priority doesn't work as expected #3982

deivid-rodriguez opened this issue Sep 30, 2020 · 2 comments · Fixed by #3655 or #4609
Labels
type: bug report

Comments

@deivid-rodriguez
Copy link
Member

In a situation like the following:

# my-private-gem.gemspec
# ...
gem.dependency("my-another-private-gem")

# Gemfile
source 'https://my-private-server' do
  gem 'my-private-gem'
end

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.

Originally posted by @rafaelfranca in #3948 (comment)
@deivid-rodriguez deivid-rodriguez changed the title Global vs block rubygems source priority doesn't work as expected Global vs block gem sever source priority doesn't work as expected Sep 30, 2020
@deivid-rodriguez deivid-rodriguez changed the title Global vs block gem sever source priority doesn't work as expected Global vs block gem server source priority doesn't work as expected Sep 30, 2020
@sonalkr132
Copy link
Member

Can confirm this issue exists. bundler doc says:

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.

@deivid-rodriguez deivid-rodriguez mentioned this issue Feb 13, 2021
Merged
4 tasks
@reedloden reedloden mentioned this issue May 10, 2021
Merged
@deivid-rodriguez deivid-rodriguez mentioned this issue May 19, 2021
Merged
4 tasks
@deivid-rodriguez
Copy link
Member Author

#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.

@services-db services-db bot mentioned this issue Dec 22, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: bug report
Projects
None yet
Milestone
No milestone
2 participants
@deivid-rodriguez @sonalkr132