New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
duncan opened this Issue Sep 14, 2010 · 20 comments

Comments

Projects
None yet
@duncan

duncan commented Sep 14, 2010

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

This comment has been minimized.

Show comment
Hide comment
@jury

jury Sep 14, 2010

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.

jury commented Sep 14, 2010

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

This comment has been minimized.

Show comment
Hide comment
@trak3r

trak3r commented Sep 14, 2010

+1

@clarkware

This comment has been minimized.

Show comment
Hide comment
@clarkware

clarkware Sep 14, 2010

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.

clarkware commented Sep 14, 2010

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

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Sep 16, 2010

Contributor

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?

Contributor

wycats commented Sep 16, 2010

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

This comment has been minimized.

Show comment
Hide comment
@duncan

duncan Sep 16, 2010

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 :)

duncan commented Sep 16, 2010

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

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Oct 15, 2010

Member

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?

Member

indirect commented Oct 15, 2010

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

This comment has been minimized.

Show comment
Hide comment
@tpope

tpope Nov 21, 2010

Contributor

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.

Contributor

tpope commented Nov 21, 2010

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

This comment has been minimized.

Show comment
Hide comment
@ixti

ixti Jul 5, 2013

Member

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

Member

ixti commented Jul 5, 2013

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

@ixti ixti closed this Jul 8, 2013

@lnigra

This comment has been minimized.

Show comment
Hide comment
@lnigra

lnigra May 26, 2014

"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.

lnigra commented May 26, 2014

"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

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect May 26, 2014

Member

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

Member

indirect commented May 26, 2014

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

@trans

This comment has been minimized.

Show comment
Hide comment
@trans

trans Mar 20, 2015

Contributor

@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.

Contributor

trans commented Mar 20, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Mar 20, 2015

Member

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.

Member

indirect commented Mar 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@franklinyu

franklinyu Jan 28, 2017

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.

franklinyu commented Jan 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Jan 28, 2017

Member

Same file, different name

Member

segiddins commented Jan 28, 2017

Same file, different name

@davecb

This comment has been minimized.

Show comment
Hide comment
@davecb

davecb Sep 10, 2017

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.

davecb commented Sep 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Sep 10, 2017

Member

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

Member

segiddins commented Sep 10, 2017

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

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Sep 10, 2017

Member

(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.)

Member

indirect commented Sep 10, 2017

(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

This comment has been minimized.

Show comment
Hide comment
@godfat

godfat Sep 14, 2017

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?

godfat commented Sep 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Sep 14, 2017

Member

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

Member

indirect commented Sep 14, 2017

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

@godfat

This comment has been minimized.

Show comment
Hide comment
@godfat

godfat Sep 15, 2017

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

godfat commented Sep 15, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment