Gemfile.lock is the wrong file extension for the file's purpose.

[duncan]

For better or worse, Gemfile.lock is a poor name choice. The .lock extension is a long used UNIX indication that a resource is locked for changing or update by a process. It's as entrenched a convention as .profile or the like. When I was a sysadmin, back in the stone ages, it wasn't unusual to see scripts that would remove any hinky .lock files on system startup anywhere they existed on the system. Not that those were very smart scripts, but... the expectation is that a .lock file is a transitory thing that can be vaporized.

In other words, Bundler's use of this extension is running headlong into a multiple-decade long UNIX convention. When I first saw it, it was like watching one culture clash right into another.

Not wanting to poke a hole in a naming convention without a counter proposal, here's a suggestion: use Gemfile.manifest as a formal name for this file. After all, that's what Bunder is doing when it creates it--itemizing everything that needs to go into the box and writing it down.

(btw, Bundler is good sauce. I like it.)

-Duncan

[jury]

Gemfile.manifest is a decent choice. You might also consider .bundler, .bmf (bundler manifest file), .gmf (gem manifest file), etc.

I agree that this naming is unfortunate.

[trak3r]

+1

[clarkware]

Naming it after the Rails environment would be interesting, especially if Rails would key it off RAILS_ENV. So Gemfile.production would be the "locked" version of the gems that you want to deploy when in the production environment. Seems like that's the typical use case anyway.

[wycats]

It would be a pretty serious backward compatibility problem to rename it at this point. Does this naming cause any real-world problems, or is it just a naming convention clash that could cause confusion?

[duncan]

Yehuda, I'm sensitive to that argument, and I wish I'd made a suggestion a while ago when things were pre 1.0. Daggumit. In order to work at this point, it would have to be some sort of a phased thing. Pick up Gemfile.lock if it's there, suggest changing it, etc. I'd be happy to pitch in the work to make it happen if you do decide that you'd like to do it.

Favorite story told to me about Makefiles: Apparently fixing tab/space sensitivity in makefiles was rejected early on by the author of make by citing the installed base. It'd been a few months since it was released and there were already many dozens of users using it. Of course, that was how many decades ago and how many people have had to deal with it since.

In reality, it's only going to be a real-world problem for a small number of people and then only if they haven't seen what the purpose of the file is and kill it without thinking because they assume it's a temp file. Because .lock does mean .tmp. Even then, since it can be recreated, it's not fatal. Mostly, it's a nasty metallic taste to see it there. Kind of like typing "public static void main(String[] args)" is nasty to some :)

[indirect]

I'm currently leaning towards automatically transitioning to "Gemlock" in 1.1. It will (hopefully) be obvious and apparent to current Bundler users, but lack the .lock extension that makes it seem deletable.

It should be pretty easy to print a "add the new file to source control" message when this rename happens. Anybody else have thoughts?

[tpope]

To add another data point, I recently witnessed in #git on freenode a Ruby/Git amateur be successfully convinced to remove Gemfile.lock from version control by a couple of Git experts who had no context for what that file was but assumed it to fall under the old UNIX convention. So yes, this is definitely confusing people in practice. Gemlock sounds reasonable enough to me.

[ixti]

Speaking of alternative names, I think .gems or even .bundler/gems would be more appropriate name.

Anyway I believe everyone knows now that Gemfile.lock has nothing to do with UNIX conventions nowadays and renaming will only confuse IMHO. So I think this issue should be closed. :D

[lnigra]

"Anyway I believe everyone knows now that Gemfile.lock has nothing to do with UNIX conventions"

Yes, but everyone also knows that .lock indicates a temporary file and also that it may be in use. As such, could reasonably be ignored by file sync apps. The issue is closed, but you might re-consider. Insync google drive app ignores it - a reasonable thing for them to do but Gemfile.lock makes it inconvenient for me to keep working directories synced among my workstations.

[indirect]

@lnigra the default file name cannot be changed until Bundler 2.0, but it is likely to happen then.

[trans]

@indirect A reminder that non-Rails project do not check-in the lock file. As such a developer I often wish the lock file could be a hidden dot file and out of the way. But I understand that is less than ideal for Rails developers and/or if alternate Gemfiles are needed. Which is also why Gemlock might not be a good choice. I have seen projects that have multiple Gemfiles -- I have never done it, but I suppose it is to use/test various dependency configurations. Perhaps Bundler has improved such that is not ever necessary anymore, but if not, it needs to be considered, i.e. the extension keeps the files separate but related, e.g. AltGemfile and AltGemfile.lock.

Personally I don't see the problem with .lock. It is similar enough to a temporary file in that it can easily be recreated and it gets updated regularly. But if it is going to change, then perhaps .bundle make's the most sense.

Another idea, let a configuration option in the Gemfile itself specify the name of its lock file. For example, in a generic Ruby project I could imagine adding:

lockfile ".bundle"

Not 100% sure if that's possible (or even desirable) but it would offer the most flexibility.

[indirect]

We've been expanding in the direction of allowing the lockfile name to be configured, and it may even be possible already. We've also shipped support for files named gems.rb and gems.locked, if present.

Ultimately, I expect that in Bundler 2.0 the Gemfile will default to gems.rb, and the lockfile name will be able to be configured per project.

[FranklinYu]

Sorry if this looks dumb, but is there any difference in syntax between Gemfile and gems.rb, or it's merely a rename? What about Gemfile.lock and gems.locked? I didn't find gems.rb mentioned in the documentation at all.

[segiddins]

Same file, different name

[davecb]

My expectation is that it's a temporary file and will be released when the changes to the file without lock have been completed.
I still write "mv x x.lock; sed 'some expression' <x.lock >x; rm lock", knowing that in Unix, mv is one of the atomicity primities.
A non-misleading name would be desirable.

[segiddins]

gems.rb will be the default in the next version of Bundler

[indirect]

(and once the Gemfile is instead named gems.rb, the locked gems list will be stored in gems.locked, so I think this ticket is now resolved.)

[godfat]

I might be late, but why .rb if it's not a Ruby file? Can we pick something else which doesn't end with .rb if they're not Ruby file?

[indirect]

@godfat it is literally a ruby file, though, and we "parse" it using eval. do you feel like it is not ruby somehow?

[godfat]

@indirect Oh, you're right. Sorry I was confused with the lock file. Not sure what I was thinking.