Bundler 2.2.10 breaks with multi-source error gems that point to themselves using path

[rafaelfranca]

Using this Gemfile:

https://github.com/rails/rails/blob/907cb05dce964e4593e02f52c45924f4401a66c0/Gemfile

We get this error:

Fetching https://github.com/QueueClassic/queue_classic.git
Fetching https://github.com/resque/redis-namespace.git
Fetching https://github.com/matthewd/websocket-client-simple.git
Fetching https://github.com/brianmario/mysql2.git
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies......
The gem 'activesupport' was found in multiple relevant sources.
* rubygems repository https://rubygems.org/ or installed locally
* source at `.`
You must add this gem to the source block for the source you wish it to be
installed from.

[deivid-rodriguez]

It's probably a duplicate of #4380?

[rafaelfranca]

Possibly. I know it is caused by bundler not knowing from which source the indirect dependency should come. This is the same problem that made disable_multisource config unusable. That behavior require users to specify almost every single indirect dependency in the Gemfile because bundler can't infer which source has precedence over the others.

This is the diff I had to do in a Rails app to be able to make the app work with that option enabled:

While I see how that feature increase security, it decrease significantly Bundler usability. Now to upgrade Rails in those apps we need to unlock every single subdependencies of Rails.

[deivid-rodriguez]

Well, the feature was not designed like that, this is a bug :(. Can you try whether #4381 fixes the issue?

[deivid-rodriguez]

I was able to reproduce this and confirmed that #4381 doesn't fix it. I'll have a look now.

[deivid-rodriguez]

In this case, I believe when you're developing code locally by using the gemspec or path sources, you always expect your local code to be used and there's no ambiguity here. So I think we can manually exclude these sources from the check. I'll update #4381 with that change.

[dedene]

I also see this behavior with 2.2.10 when source from a remote private rubygems repo. 2.2.9 does not have this problem.

[deivid-rodriguez]

Pushing a fix in a few minutes 👍.

By the way, this also shows a different issue. Even if the sources could be considered ambiguous, I don't think there's any ambiguity in this particular case, because rubygems.org doesn't have activesupport 7.0.0.alpha. The check for ambiguity should use name + resolved version, not just name. The fix I'm pushing should fix the path and gemspec source case in general, but I'll try to further improve improve this in the future.

[deivid-rodriguez]

Our CI revealed that in the case where there's a real ambiguity, it's not really guaranteed that the path source will always end up being chosen. So I changed the PR to fix the case when there's no real ambiguity for now, and will follow up with preferring always path sources in the future.

I believe the current approach should work fine for most Rails cases. It might still give you trouble when run from release branches, depending on the whether the local version ever matches the released version, but as I said I'll try to address that issue too in the future.

[rafaelfranca]

Thank you for working so quickly on this.

[deivid-rodriguez]

No problem, I'm responsible for the mess caused, so I want to fix it as soon as possible.

[deivid-rodriguez]

For now I reverted the change that caused this issue and released that as 2.2.11. I'll try to reintroduce the secure mode I wanted to introduce without breaking your use case in future releases.