Gemfile.lock is recommended to be in source control

[pboling]

Prior to 2017 it was common, and considered best practice, to exclude Gemfile.lock from version control, but then things changed, and the Bundler team decided, after much discussion, that it is best to commit it for both libraries and apps.

In the official bundler guide to creating a RubyGem, it is in bold, and italic font, that the file is extremely important, and it states that it should always be in version control.

But the previous common practice was very widely known for many years, so it is taking a long time to overturn.

Keeping it in version control does make CI more complex, because many different Rubies cannot share the same Gemfile due to Ruby version contraints of the dependencies resulting in differing installed versions of gems.

With ruby gems (not apps) I use the rubric:

Gemfile is for local development only; never CI

Accounting for this has a side benefit of bringing additional structure and stability to CI. Failures due to changes in dependency resolution become effortlessly apparent.

I would recommend appraisal2 to handle multiple gemfiles, but I am also quite handy at implementing a similar solution without appraisal2 (in fact that is precisely what I did for appraisal2's test suite).

• https://github.com/appraisal-rb/appraisal2/

[pboling]

I'll create a PR for this but it will conflict with other PRs that remove dependencies, so I'll update it depending on which gets merged first.

[kou]

I don't want to add Gemfile.lock to this repository:

• We want to run CI jobs with the latest dependencies
  • We don't want to hide failures by keeping using old dependencies
• We can use Dependabot to update dependencies in Gemfile.lock but we can always use the latest version by not version controlling Gemfile.lock

[hsbt]

The guide of bundler is for application, not library and framework. We should add that context to the official guide.

[pboling]

No, @hsbt there are already separate guides for bundler usage with apps and bundler usage with gems. Both guides explicitly say the lockfile should be committed, and the quote and screenshot are from the guide for gems. The link reference is to the guide for gems, not applications.

@kou I completely agree with you.

Gemfiles for CI should not have their .lock committed, and this is why the Gemfile for CI should never be the same Gemfile as the one for local development.

I am pioneering a pattern which enables this style of development that I call "modular gemfiles".

A decent example of the pattern would be my kettle-soup-cover repo's split between the main Gemfile, and the CI gemfiles in gemfiles/<workflow name>.gemfile.

See: https://github.com/kettle-rb/kettle-soup-cover

[pboling]

Please leave your mind open on this until you see what the solution looks like. It is quite elegant, IMO.

[hsbt]

OK, I remove that sentence。I'm a primary maintainer of Bundler.

[pboling]

You can certainly do that, but it will bring bundler's documentation into conflict with itself in other places. We debated this a great deal as a community a few years ago, and the outcome was what we now have. Changing it would be to reopen and relitigate the issue. I'm not sure what we would gain from that.

[kou]

I also use multiple Gemfiles when it's needed. For example: https://github.com/test-unit/test-unit-activesupport/tree/master/gemfiles

But I think that we don't need multiple Gemfiles in this repository.

[pboling]

We do actually need multiple gemfiles, and the devcontainer for Ruby 2.5 proves it. If you want to run latest Ruby on your machine natively, and Ruby 2.5 in the devcontainer with the filesystem mounted, you would have to delete and rebundle everytime you switched between them, because a single .lock can never work in both places.

[kou]

What is the difference between Gemfile for Ruby 3.4 and Ruby 2.5?
It seems that https://github.com/ruby/rexml/pull/272/files#diff-7ab2ed528f2192d10e78168bd4cdf36dbcdb098546d9fbec976b20c99497812b has the same content as the current Gemfile.

[kou]

Ah, you want to create multiple Gemfile.locks by multiple Gemfiles with the same content, right?

[pboling]

Exactly correct! :)

[kou]

Hmm. I don't think that it's a smart approach. I feel that it's just a workaround.
If we want to support the situation, I think that we can improve Bundler.

For example: In general, many build system has "source directory" and "build directory" concepts. If Bundler has the same concepts, Bundler will generates "Gemfile.lock" to "build directory" not "source directory". Bundler users can have multiple "build directories" that have separated "Gemfile.lock".

[kou]

For the devcontainer case, we can copy the current Gemfile in the setup script. We don't need to have multiple Gemfiles.