Bundler 4 is re-resolving dependencies every run

[voxik]

Describe the problem as clearly as you can

Having this test setup:

$ ruby -v
ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux]

$ echo 'gem "minitest"' > Gemfile

$ cat <<EOF > test.rb  
require "bundler"
Bundler.setup
EOF

Bundler 4.0 seems to try to resolve the dependencies every time:

$ bundle -v
4.0.0.beta1

$ ruby test.rb 
Resolving dependencies...

$ ruby test.rb 
Resolving dependencies...

Bundler 2.6 resolves the dependencies just once:

$ bundle -v
Bundler version 2.6.9

$ ruby test.rb 
Resolving dependencies...

$ ruby test.rb

Or at least does not print the message all the time ;)

Interestingly, when the Gemfile.lock is created by Bundler 2.6, Bundler 4.0 is happy with it 🤷 This is the diff between Gemfiles:

--- bundler-2.6.9
+++ bundler-4.0.0.beta1
@@ -10,5 +10,8 @@
 DEPENDENCIES
   minitest
 
+CHECKSUMS
+  minitest (5.26.0)
+
 BUNDLED WITH
-   2.6.9
+  4.0.0.beta1

BTW, not sure where the CHECKSUMS sections comes from and how it is supposed to be populated, but I can't see any checksum there. Can it be because minitest is actually installed via RPM?

[voxik]

BTW, not sure where the CHECKSUMS sections comes from and how it is supposed to be populated, but I can't see any checksum there. Can it be because minitest is actually installed via RPM?

Tried install minitest from RubyGems but the results is not any different 🤷

[Edouard-chin]

Edit: Deleting my comment as I misread the issue, sorry.

[Edouard-chin]

Dug a bit and the first commit that introduces the new behaviour is 47c3dc1

Basically when running Bunder.setup without an existing Gemfile.lock, Bundler won't compute the gems checksums (as it would if you ran bundle install first).
We then end up with a Gemfile.lock with empty checksums and as a side effect when re-running the script, Bundler will consider that resolving is needed.

rubygems/bundler/lib/bundler/definition.rb

Lines 616 to 617 in 2494239

	@locked_spec_with_missing_checksums ||
	@locked_spec_with_empty_checksums ||

---

If Bundler.setup gets called without a Gemfile.lock, we coul compute the checksums similar to this PR #9004 (since we know that all gems are installed as otherwise Bundler.setup will bail out).

[hsbt]

@voxik Thank you for your feedback of Bundler 4.

@Edouard-chin Also thank you for your confirmation.

I also could reproduce this.

1. Bundler.setup didn't add CHECKSUMS. So, bundler resolved dependencies every time for CHECKSUMS.
2. bundle i with initial time or bundle lock --add-checksums couldn't add sha256 entries into CHECKSUMS section, if we didn't add source "https://rubygems.org".

CHECKSUMS section will be added with source "https://rubygems.org" into Gemfile and run rm Gemfile.lock && bundle i or bundle lock --add-checksums. After that, bundler don't resolve with Bundler.setup.

We may need to skip to handle CHECKSUMS if source section is not available.

[voxik]

CHECKSUMS section will be added with source "https://rubygems.org" into Gemfile

Interesting. I am not sure this is complete picture, because I have initially hit the issue with environment setup like this:

# Create simple test file which satisfies the test suite.	
cat << EOF > gemfiles/test.gemfile	
source "https://rubygems.org"	

gem "minitest"	
gem "mocha"	
gem "test-unit" 

gemspec path: "../"
EOF
BUNDLE_GEMFILE=gemfiles/test.gemfile bundle install --local

coming from the Fedora's rubygem-shoulda-context package. Then I have tried to simplify the test case and ended up without source.

But then it might come to the play that in Fedora we don't keep the cached gems around? Not sure. Will need to dig deeper a bit more.

[hsbt]

Will need to dig deeper a bit more.

Yes. I also not sure why shoulda-context couldn't add checksums yet.

My investigation is here:

❯ echo 'gem "minitest"' > Gemfile
❯ bundle i
Resolving dependencies...
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
❯ cat Gemfile.lock
GEM
  specs:
    minitest (5.26.2)

PLATFORMS
  arm64-darwin-25
  ruby

DEPENDENCIES
  minitest

CHECKSUMS
  minitest (5.26.2)

BUNDLED WITH
  4.0.0.beta1
❯ rm Gemfile.lock
❯ vim Gemfile # Added source "https://rubygems.org"
❯ bundle i
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
❯ cat Gemfile.lock
GEM
  remote: https://rubygems.org/
  specs:
    minitest (5.26.2)

PLATFORMS
  arm64-darwin-25
  ruby

DEPENDENCIES
  minitest

CHECKSUMS
  minitest (5.26.2) sha256=f021118a6185b9ba9f5af71f2ba103ad770c75afde9f2ab8da512677c550cde3

BUNDLED WITH
  4.0.0.beta1

[voxik]

Aha, I have messed up the second attempt somehow. Sorry. I have rather deleted the previous comment

[voxik]

I have rather extracted the "source" issue into separate ticket, because that seems to be clear case.

[voxik]

This is the check which later triggers the 'Resolving dependencies...' :

rubygems/bundler/lib/bundler/definition.rb

Line 617 in 39ff415

@locked_spec_with_empty_checksums ||

and ATM I suspect this change 05199ae to be the reason for the repetitive checks.

If I read the change correctly, any time there is entry in CHECKSUMS section without actual checksum, Bundler tries to fix this. This to me is odd behavior. If there was some warning. Or why this should be even enabled to create such incorrect section?