tomrossi7
commented
1 year ago +1
Closed quiro91 closed 1 year ago
tomrossi7
commented
1 year ago +1
ehamby-evi
commented
1 year ago I am experiencing the same error as well now when running bundle install locally after pulling in some project changes. Version is 2.2.28 though and hadn't updated bundler from when it last worked.
K-S-A
commented
1 year ago The workaround:
BUNDLE_IGNORE_FUNDING_REQUESTS=1 bundle install@K-S-A Any advice for bundler version below 2.3 where that seems to be first available to set?
K-S-A
commented
1 year ago @ehamby-evi, I can only suggest adding the current platform to the lockfile. For example:
bundle lock --add-platform x86_64-linux
# or
bundle lock --add-platform arm64-darwin-22Related line in the codebase: https://github.com/rubygems/rubygems/blob/bundler-v2.2.28/bundler/lib/bundler/definition.rb#L227
ehamby-evi
commented
1 year ago @K-S-A Thanks! I'll look into that.
khalidMahmod
commented
1 year ago The workaround:
BUNDLE_IGNORE_FUNDING_REQUESTS=1 bundle install
This worked for me. Thanks
duckinator
commented
1 year ago I made a simplified testcase, and found what appears to be the cause.
Fascinatingly, that Gemfile.lock is required to reproduce this. If the specs: list has even one item in it, it works.
Regenerating the Gemfile resolves it, however because the exact Gemfile + fastlane/Pluginfile seem to result in an endless loop.
Potential solution for @quiro91's specific situation (even though this is still two bugs on our end): if possible, specify an exact version for fastlane in the Gemfile. At this point deleting and regenerating the Gemfile.lock should be enough to make it work. In my testing, I went with gem 'fastlane', '= 2.210.0'.
On the Bundler side, we have the original bug reported here, and a new testcase for resolver weirdness.
duckinator
commented
1 year ago I'll dig into testing the two potential fixes later and make a PR as appropriate. (Probably either tonight or tomorrow.)
For now, I'll document everything I've figured out.
Looking at the code Bundler::CLI::Common.output_fund_metadata_summary, the code is treating as definition.requested_dependencies a subset of definition.specs.
As best I can tell, this is done based on these assumptions:
Gemfile.lock is generated by Bundler.Gemfile.lock, anything under DEPENDENCIES should also be under specs: in the resulting file, because specs: are by definition the combination of DEPENDENCIES and all indirect dependencies.As long as both assumptions 1 and 2 are true, then definition.requested_dependencies is a subset of definition.specs, and it's fine.
This Gemfile.lock contains a populated DEPENDENCIES, but an empty specs:. This means one of the two assumptions is broken. Either the Gemfile.lock was not generated by Bundler, or there is a way for Bundler to generate a Gemfile.lock with an empty specs:.
Patch (untested).
diff --git a/bundler/lib/bundler/cli/common.rb b/bundler/lib/bundler/cli/common.rb
index d654406f65..0cd8976ce0 100644
--- a/bundler/lib/bundler/cli/common.rb
+++ b/bundler/lib/bundler/cli/common.rb
@@ -20,6 +20,8 @@ def self.output_fund_metadata_summary
current_dependencies = definition.requested_dependencies
current_specs = definition.specs
+ return if current_specs.count < current_dependencies.count
+
count = current_dependencies.count {|dep| current_specs[dep.name].first.metadata.key?("funding_uri") }
return if count.zero?This approach instinctively feels more robust to me, because it also covers the situation where current_dependencies contains something that current_specs does not, but the counts work out fine.
Patch (also untested).
diff --git a/bundler/lib/bundler/cli/common.rb b/bundler/lib/bundler/cli/common.rb
index d654406f65..cb1c5ab010 100644
--- a/bundler/lib/bundler/cli/common.rb
+++ b/bundler/lib/bundler/cli/common.rb
@@ -20,7 +20,10 @@ def self.output_fund_metadata_summary
current_dependencies = definition.requested_dependencies
current_specs = definition.specs
- count = current_dependencies.count {|dep| current_specs[dep.name].first.metadata.key?("funding_uri") }
+ count = current_dependencies.count {|dep|
+ current_specs[dep.name].first.metadata.key?("funding_uri") \
+ if current_specs.has_key?(dep.name)
+ }
return if count.zero?
Opened #6322 for the resolver problem I discovered here.
duckinator
commented
1 year ago Opened #6409, which should fix the NoMethodError being raised.
deivid-rodriguez
commented
1 year ago This was fixed by #6423.
Describe the problem as clearly as you can
Running
bundle installdoes not work as expected after upgrading to the latest bundler version (previous was 2.1.4). This is the output I get when runningbundle install:Environment
Bundler Build Metadata
Bundler settings
Gemfile
Gemfile
fastlane/Pluginfile
Gemfile.lock
I admit I'm no expert in Ruby, and I was just trying to upgrade some scripts nobody had touched for a while (they run fine with bundler 2.1.4).