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  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 .
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 ?
 File lock projects:
https://github.com/gofrs/flock https://github.com/MichaelS11/go-file-lock https://github.com/juju/fslock
 Projects that implement their own file locking:
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
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.
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.
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/sync, or someplace else entirely?
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
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.
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 .
- go net/http/httputil: ReverseProxy does not set host header correctly
- x/tools/cmd/godoc: show internal packages when explicitly requested
- x/playground: timeout compiling trivial code that imports net/http
- encoding/json: decoding into existing map pointer values unexpectedly reallocates them
- cmd/go: allow fuzzing multiple targets per package
- I can't install go on freebsd 12.2
- go x/image/bmp: support 1-bit format
- go: don't change the libraries in 1.18