LockfileParser: Why can "bundler" appear in dependencies but not specs?

[amomchilov]

I'm trying to better understand the various attributes of Bundler::LockfileParser, and discovered something interesting.

Taking Rubocop's repo as an example, we can see that it has an explicit dependency on bundler:

https://github.com/rubocop/rubocop/blob/c1c320b273b687c5066739a310377c7a1f283d3e/Gemfile#L9

This shows up in #dependencies:

parser = Bundler::LockfileParser.new(Bundler.read_file(Bundler.default_lockfile))
parser.dependencies.keys.include?("bundler") # => true

But not in #specs:

parser.specs.map(&:name).include?("bundler") # => false

I think this is happens because the generated Gemfile.lock has it in the DEPENDENCIES section, but not the GEM.specs section:

Here's the full Gemfile.lock

PATH
  remote: .
  specs:
    rubocop (1.56.4)
      base64 (~> 0.1.1)
      json (~> 2.3)
      language_server-protocol (>= 3.17.0)
      parallel (~> 1.10)
      parser (>= 3.2.2.3)
      rainbow (>= 2.2.2, < 4.0)
      regexp_parser (>= 1.8, < 3.0)
      rexml (>= 3.2.5, < 4.0)
      rubocop-ast (>= 1.28.1, < 2.0)
      ruby-progressbar (~> 1.7)
      unicode-display_width (>= 2.4.0, < 3.0)

GEM
  remote: https://rubygems.org/
  specs:
    addressable (2.8.5)
      public_suffix (>= 2.0.2, < 6.0)
    asciidoctor (2.0.20)
    ast (2.4.2)
    base64 (0.1.1)
    bigdecimal (3.1.4)
    bump (0.10.0)
    crack (0.4.5)
      rexml
    debug (1.9.1)
      irb (~> 1.10)
      reline (>= 0.3.8)
    diff-lcs (1.5.0)
    docile (1.4.0)
    hashdiff (1.0.1)
    io-console (0.7.2)
    irb (1.11.2)
      rdoc
      reline (>= 0.4.2)
    json (2.6.3)
    language_server-protocol (3.17.0.3)
    memory_profiler (1.0.1)
    parallel (1.23.0)
    parser (3.2.2.3)
      ast (~> 2.4.1)
      racc
    psych (5.1.2)
      stringio
    public_suffix (5.0.3)
    racc (1.7.1)
    rainbow (3.1.1)
    rake (13.0.6)
    rdoc (6.6.2)
      psych (>= 4.0.0)
    regexp_parser (2.8.1)
    reline (0.4.3)
      io-console (~> 0.5)
    rexml (3.2.6)
    rspec (3.12.0)
      rspec-core (~> 3.12.0)
      rspec-expectations (~> 3.12.0)
      rspec-mocks (~> 3.12.0)
    rspec-core (3.12.2)
      rspec-support (~> 3.12.0)
    rspec-expectations (3.12.3)
      diff-lcs (>= 1.2.0, < 2.0)
      rspec-support (~> 3.12.0)
    rspec-mocks (3.12.6)
      diff-lcs (>= 1.2.0, < 2.0)
      rspec-support (~> 3.12.0)
    rspec-support (3.12.1)
    rubocop-ast (1.29.0)
      parser (>= 3.2.1.0)
    rubocop-capybara (2.19.0)
      rubocop (~> 1.41)
    rubocop-factory_bot (2.24.0)
      rubocop (~> 1.33)
    rubocop-performance (1.19.0)
      rubocop (>= 1.7.0, < 2.0)
      rubocop-ast (>= 0.4.0)
    rubocop-rake (0.6.0)
      rubocop (~> 1.0)
    rubocop-rspec (2.24.1)
      rubocop (~> 1.33)
      rubocop-capybara (~> 2.17)
      rubocop-factory_bot (~> 2.22)
    ruby-progressbar (1.13.0)
    simplecov (0.17.1)
      docile (~> 1.1)
      json (>= 1.8, < 3)
      simplecov-html (~> 0.10.0)
    simplecov-html (0.10.2)
    stackprof (0.2.25)
    stringio (3.1.0)
    test-queue (0.11.0)
    unicode-display_width (2.4.2)
    webmock (3.19.1)
      addressable (>= 2.8.0)
      crack (>= 0.3.2)
      hashdiff (>= 0.4.0, < 2.0.0)
    yard (0.9.34)

PLATFORMS
  arm64-darwin-22
  arm64-darwin-23

DEPENDENCIES
  asciidoctor
  bigdecimal
  bump
  bundler (>= 1.15.0, < 3.0)
  debug
  memory_profiler
  rake (~> 13.0)
  rspec (~> 3.7)
  rubocop!
  rubocop-performance (~> 1.19.0)
  rubocop-rake (~> 0.6.0)
  rubocop-rspec (~> 2.24.0)
  simplecov (~> 0.10, < 0.18)
  stackprof
  test-queue
  webmock
  yard (~> 0.9)

BUNDLED WITH
   2.4.1

Why is that?

[deivid-rodriguez]

I think it's because it's the bundler gem itself, and that one currently gets excluded from the SPECS lockfile section.

I guess the rationale originally was that by the time Bundler activates the gems included in the SPECS section, Bundler itself is already running so too late to try to activate the locked version of Bundler itself. We could try avoid this inconsistency in the future but I think that's the motivation for it currently being excluded.

[amomchilov]

Hey @deivid-rodriguez, thanks for taking the time to chime in. This rationale makes total sense.

I ran into this distinction when using Bundler::LockFileParser in Rubocop's implementation. If I contributed some API docs for these public methods, that clarify this stuff, would you be able to review/merge them?

rubygems/bundler/lib/bundler/lockfile_parser.rb

Lines 27 to 35 in 7316186

	attr_reader(
	:sources,
	:dependencies,
	:specs,
	:platforms,
	:bundler_version,
	:ruby_version,
	:checksums,
	)