Is .lock a poor choice on UNIX systems?

[nathany]

Adrian Lanzafame mentioned this blog post where Ruby Gems has decided to change from .lock to .locked. https://depfu.com/blog/2017/09/06/gemfiles-new-clothes

Further discussion in this issue: https://github.com/bundler/bundler/issues/694

reference: https://groups.google.com/forum/#!topic/go-package-management/MCloCV6iQ38

Builds on the naming discussion from #168 -- always learning new things.

[dcheney-atlassian]

IMO, it's too late to change now, and little concrete benefit from doing so.

[nathany]

Any change now would be unnecessary churn for sure, but maybe later on in the lifecycle:

They will probably change in the final go command integration based on that experience, and that's fine. - rsc, https://github.com/golang/dep/issues/168#issuecomment-289632454

Just leaving this here, as it's something to think about.

[sdboyer]

ugh, yeah, i wish this is something we'd considered when going through #168. could've just as easily been Gopkg.locked, or whatever.

i started trying to game out what it would look like to make the change. i think it might be doable, but it feels like it would cost quite a bit of energy to spec out a plan for it that really, really covers all the bases.

my feel is that we wait until that future [re]naming opportunity, unless we find a number of our users encountering problems with it in ways for which there aren't reasonable workarounds.

[davecb]

I read .lock files in dep as temporaries. Are they expected to persist in Go?

As scripts do not have atomic actions, the norm is to use Unix atomic actions on filesystem files, where ".lock" is a short-lived file created via mv (which is atomic). For eample, the stream editor "sed" is used thusly:

mv x x.lock sed <x.lock >x 's/this/that/g' rm x.lock

Reusing .lock or .lck for something long-lived is actively misleading and might be ill-advised[1], as uinix sysadmins and developers would, if they encountered them, consider them left-overs from a failed operation and remove them.

--dave [1. I'm a polite Canadian: an American would use some sutably coarse curse-word in place of "ill-advised"]

[peterbourgon]

One data point, nothing more: I have used UNIX for a very long time, and I have never encountered this convention. I wonder if (read: doubt) it's still meaningful.

[SamWhited]

One data point, nothing more: I have used UNIX for a very long time, and I have never encountered this convention. I wonder if (read: doubt) it's still meaningful.

One other data point: I've run into this a few times when using other tools (mostly Ruby, back when I was still doing that). I have yet to run into this problem with dep, but I've only been using it in my own projects and those at work for a short period of time.

[bradleypeabody]

A note for posterity in case this is reviewed later - IMO the issue isn't so much the ".lock" extension as the word "lock". The cases I've seen referred to describe .lock files being used in ways that are application-specific. I don't see any real-world case where Gopkg.lock is going to cause any problems with other tools. (A scenario where a script goes through and deletes all .lock files - while I'm sure someone somewhere has done this, I just don't see that's a real concern - someone somewhere has rm -Rf'ed their /usr directory too.)

That said, the word "lock" in the context of software tends to imply "temporary". You lock database records, perhaps you lock a file being edited, you acquire a lock for a critical section of code, etc - all things that happen for a period of time and then get "unlocked". So when people are expected to "git add" a "lock" file, it's a bit counter-intuitive - IMO that's the most relevant argument to change it. ".locked" is only marginally better - it still seems like a "lock".

".state" or ".status" or ".version" or ".active" might be better candidates. Then again, if the intention is to make things clearer, then why not have a .toml file extension like the other file (I mean, it is a toml file after all...). That train of thought leads to something like: "Gopkg-active.toml".

/bikeshed

[sdboyer]

sorry, meant to respond earlier. so.

it seems clear that the .lock extension is less than ideal, for the reasons given. however, i don't think the issue is critical enough to merit us spending cycles making the change, updating documentation, and having to forevermore explain to people why it changed. rather, let's take this into consideration when we're ready to make the jump into the toolchain.

[nathany]

@bradleypeabody Good thoughts. A more permanent sounding name would be good if that would mean that the question of committing the file or not doesn't even come up.

Mind you, Rust continues to use Cargo.lock and NPM uses package-lock.json, so there is precedent for using that word for this purpose.

One reason for not using Gopkg-lock.toml, which I believe was discussed in #168, is that the lock file is machine generated and not intended for humans to read or edit. Pretending it's not a toml file emphasizes that to some extent, depending partially on how your particular text editor treats the file.

[davecb]

On 17/11/17 01:03 AM, Nathan Youngman wrote:

@bradleypeabody https://github.com/bradleypeabody Good thoughts. A more permanent sounding name would be good if that would mean that the question of committing the file or not doesn't even come up.

Mind you, Rust continues to use Cargo.lock and NPM uses package-lock.json, so there is precedent for using that word for this purpose.

One reason for not using Gopkg-lock.toml, which I believe was discussed in #168 https://github.com/golang/dep/issues/168, is that the lock file is machine generated and not intended for humans to read or edit. Pretending it's not a toml file emphasizes that to some extent, depending partially on how your particular text editor treats the file.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/golang/dep/issues/1139#issuecomment-345153589, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiJkfPUZ1Ty9K9GojXhNMcroaJ1jUFnks5s3SGsgaJpZM4PQmWu.

Use due care to not give yourself technical debt.

Do the right thing, even if it is inconvenient now. It will pay you back later, and "pay it forward" to all the users of dep.

--dave

-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain