Jan Krutisch, Co-Founder at Depfu

The Bundler team currently works hard on pushing Bundler to the 2.0 release. This release will change a lot of default behavior, so it might be good to catch up with these changes way before the actual release. Some of the things that Bundler 2.0 will change are already possible with the latest releases, they’re just not default yet.

Probably one of the most visible changes is that Gemfile and Gemfile.lock will cease to exist. Well, under that name, at least. Enter gems.rb and gems.locked.

But why?

Let’s start with Gemfile. At the time when Bundler came out, the so called “Filefiles” were quite popular. There’s the Procfile introduced by Heroku and foreman, we all know Rakefile and of course, all of this was probably introduced by the mighty Makefile. Critics have voiced several arguments against this naming scheme:

  • The capitalization is odd and uncommon in the rest of the world of programming.
  • The “file” part is superfluous, it’s a bit like if Rails’ app folder would be called Appfolder. That would be weird, huh?
  • The fact that none of these have any extension makes it kind of hard to tell what’s actually in the file (hard to tell for humans, but also for editors, for example).

So the new name gems.rb addresses all of these: The name is all lowercase, the purpose is clearly stated in the name and a proper Ruby file extension makes it easy for editors to pick the right syntax highlighting and it is clear from the beginning that the contents will be Ruby code of sorts.

The gems.locked part is a bit more subtle. This issue filed by industry veteran James Duncan Davidson does a pretty good job of explaining why the .lock part of Gemfile.lock was bad (and also shows how long this has been in discussion. The issue is from 2010. Yikes.): In general, on UNIX-ish systems, .lock stands for a very specific type of file, a, you might have guessed it, lock. They are used all over the place for expressing locks on system resources and thus this Gemfile.lock thing is more confusing than helping. Specifically, locks are usually treated as temporary files and thus could be, under certain circumstances cleaned up by careless scripts.

By renaming both files, all of these problems or potential problems can be avoided.

Do we have a migration strategy?

Of course, this is a pretty radical change and so Bundler will try to soften the blow as much as possible.

Gemfile.lock and Gemfile are, as it looks, not going away. The Bundler 2.0 RFC was (after this article was first published) recently changed to remove the passage that said that Gemfile and Gemfile.lock will not work with Bundler 3.0. So, for existing projects, for the time being, nothing will change.

And, more importantly, current versions of Bundler already detect gems.rb and gems.locked and will work with them, so you could, in theory, already rename them. This way, the Bundler team can test with real world examples and iron out any bugs in the code.

One thing to point out is that the old and new do not mix, so a Gemfile will always create a Gemfile.lock and a gems.rb will always result in a gems.locked. Makes sense when you think about it, right?

Basically, the only thing that Bundler 2.0 will do differently is create a gems.rb on bundle init (and then, of course, will create a gems.locked accordingly on bundle install) and that if both Gemfile and gems.rb exist, Bundler 2.0 will prefer gems.rb instead of Gemfile.

Should I migrate now?

No, probably not. It’s not only Bundler itself that needs to support the new file names, your whole eco system needs to understand it, too. CI or deployment systems that detect Ruby projects by scanning for a Gemfile must be adapted. Currently, vendors like Heroku for example don’t have a huge incentive to support it as very few people will actually use it in their projects.

If you want to help the Bundler team testing out these changes, though, you can start using it on projects where no additional infrastructure is needed or where it can be adapted.

At Depfu, we just added support for gems.rb and gems.locked. We like to be prepared :)

Note: We’ve changed this article slightly on 29th of September 2017 after we’ve learned that the Bundler team decided to not deprecate Gemfile & Gemfile.lock for the time being by watching this Talk by Colby Swandale at Rubykaigi which also explains a couple of other changes that will come with Bundler 2.0.