Gemfile's new clothes
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.lock will cease to exist. Well, under that name, at least. Enter
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.
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 going to work all through the 2.x series of Bundler and will stop working with 3.0, so there’s plenty of time to rename two files in your repo.
And, more importantly, current versions of Bundler already detect
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).
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.locked. We like to be prepared :)