go proposal: make the internal lockedfile package public

An internal filelock pkg can be found here: https://pkg.go.dev/cmd/go/internal/lockedfile/internal/filelock

A few projects are implementing file locking [1] but they do not seem to be maintained and I think they are not as nice as the internal filelock pkg I mentioned before. As a result some projects are doing their own version of it [2].

I suggest we make the filelock pkg public as I think this could be beneficial to the mass.

I'd be glad to do it given some pointers, like where to put it ?

Thanks !

[1] File lock projects:

https://github.com/gofrs/flock https://github.com/MichaelS11/go-file-lock https://github.com/juju/fslock

[2] Projects that implement their own file locking:



Asked Dec 31 '21 11:12
avatar azr

6 Answer:

the filelock of go-internal is in an internal pkg

I'm not sure why that is, perhaps @rogpeppe or @myitcv can answer. Have you looked at https://godoc.org/github.com/rogpeppe/go-internal/lockedfile? That seems like a public, higher-level version of it.

That aside, sure, there are some upsides to having this in the standard library. But I think the downsides are generally greater:

  • Once a package is public, it can never have backwards incompatible changes
  • The standard library can grow, but never shrink in size
  • Once the number of users greatly outgrows just cmd/go, the maintainers will probably have extra work responding to issues, reviewing patches, and fixing bugs that might not even affect cmd/go

I think a far better proposal would be to include this in one of the official external repos, like x/sync. Once that's worked well for a while, then it can be part of the public standard library. This is the path that context took, for example.

Answered Sep 03 '19 at 13:41
avatar  of mvdan

lockedfile fits right to our usage and lockedfile doesn't have the filelock.ErrNotSupported. But yes lockedfile could work here.

Yes, I agree this should probably be in an x/ pkg 🙂, I only suggested we make the filelock pkg public and agree this would be a bit quick to put in the stdlib.

Answered Sep 03 '19 at 14:20
avatar  of azr

At this point we've been using lockedfile for a full release cycle and it seems mostly fine, modulo what appears to be an AIX kernel bug (#32817). I'd be fine with making it public.

Then the question is where to put it: x/sys, x/exp, x/sync, or someplace else entirely?

Answered Sep 03 '19 at 21:25
avatar  of bcmills

@azr, filelock should remain internal — it's much too subtle to use on its own. (In particular, if you want your program to remain portable, you have to be very careful to stick to a narrow subset of the possible modes of use.)

If folks discover other interesting use-cases for filelock, then we can probably add more ergonomic packages to address those use-cases while still keeping filelock internal.

Answered Sep 04 '19 at 12:55
avatar  of bcmills

To be clear: I support making the lockedfile package itself public — I just want to ensure that the lockedfile/internal/filelock package remains internal to it.

Answered Sep 25 '19 at 18:39
avatar  of bcmills

It's in the "incoming" list. We move proposals from "incoming" to "active" as we have bandwidth to handle them. See https://go.googlesource.com/proposal/+/refs/heads/master/README.md .

Answered Jan 08 '21 at 20:26
avatar  of ianlancetaylor