Using different Bundler versions

If you use rbenv to manage the myriad of git repositories that use ruby, I assume you’re well aware that not all projects share the same version of ruby - 3.0.2, 2.7.2, 2.6.6, 2.5.0, and many more.

That’s fine. rbenv changes the ruby environment to the appropriate version automatically.

However, this is not always the case. Suppose there are two or more projects that share the same version of ruby. Therefore, they share the same dependency folder. This is great. The matching gems are shared between the projects. No extra space is needed for that version of ruby. But when it comes to Bundler, it’s a different story: the bundler gem is always set to the latest installed version.

It may seem that it is not too important to use only the latest version. Normally, we are talking about different minor versions in the same major version range: 2.X.X.

But if like me, you care about having a useful and reliable git log, then not using the same version of bundler is a bit annoying.

As you know, bundler uses Gemfile to specify which gems and their version range are needed for the project. To keep track of the specific version installed, another file is automatically created after bundler: Gemfile.lock.

Have you ever checked what is written at the end of Gemfile.lock?

BUNDLED WITH
	2.2.17

Yes, that’s it. The version of Bundler used.

And what happens when you commit to different git repositories using the same ruby version but a different bundler?

Well, the bundler version changes when the bundle update is executed. Also, when new gems are installed. And this change is committed along with unrelated modifications. Bad git logging!

It seems that it is not a big problem here. But when there are many contributors, there is a possibility that the Gemfile.lock is updated several times a week. Or even in a day. Especially, because not everyone is using the same bundler version.

Happily, in the revision step, the modification can be localized and corrected.

But how do you prevent a different version of bundler from modifying the Gemfile.lock? Should the contributor downgrade or upgrade bundler?

That doesn’t seem like a good approach. The developer would have to downgrade the version or update as many times as he changes the project.

Luckily, there is a better way.

The guys at RubyGems have provided the function to specify which version of the bundler to run. Just pass as the first argument the version number wrapped by underscores to bundler.

bundle _X.X.X_ update

I’ve looked if there’s a way to set it globally, but there doesn’t seem to be.

Anyway, I’m pretty sure something can be done using rbenv hooks or with an external utility like direnv to automate the process by getting the version number under the BUNDLED WITH comment and automatically run the appropriate bundler version. But that is another story.