proposal: cmd/go: build argument to disable readonly $GOPATH/pkg/mod

[Psykar]

What did you do?

This has been discussed previously:
#27161

Most build systems (buildroot et al.) expect to be able to do an rm -rf to do a completely fresh build. However, because the pkg sets it's containing directories to read only, this command will fail.

Requiring a custom command to be added to various Makefile's scattered around the place to clean this up is far from ideal.

A potential solution might be to add an environment variable to disable this read only permission change on the pkg directory.
Open to other alternatives - but ideally there needs to be a command on the BUILD side that allows rm -rf to work correctly.

[agnivade]

#27161 clearly mentions that it is intentional and will remain this way.

It would be good if your proposal addresses the issue raised by @rsc here.

[Psykar]

@agnivade - the default being read only makes complete sense to me, I'm not suggesting changing that.
I would have thought a manual flag to allow the directories to be writeable would be acceptable - to tell golang that I know what I'm doing, it's OK to not lock the directory down?

It's worth noting in this kind of scenario (embedded build systems), tests are not going to be run as part of the build process, and the whole build directory (which includes this cache directory) frequently gets removed entirely.

So we're looking for a way to allow rm -rf to work on the $GOPATH/pkg/mod directory while still blocking tests from being able to write files to this directory? The two seem mutually exclusive to me unfortunately, hence suggesting the manual flag.

(As an aside, happy to do the PR for this if it's acceptable)

[agnivade]

Marking it as a proposal.

[bcmills]

You can already run chmod u+w -R $GOPATH/pkg/mod or go clean -modcache explicitly before cleaning up.

Why would an explicit argument be more helpful than an explicit command? Seems like you have to update your configuration either way.

[pbrkr]

@bcmills: The problem for us is that we can't modify our CI system to run those commands at the start of a build. The fault here is 100% with the golang compiler, it has no valid case for removing the write bit from files & directories in the build tree.

Running git clean -xffd (which the CI system does) should be sufficient to fully clean up a build directory.

[bcmills]

@paul-betafive, how are you able to add arguments to the go command but not able to add a chmod or go clean command? Could you give some more detail on the specifics of your CI system?

[pbrkr]

We can add a chmod command after the go build command but that isn't water-tight as the build may fail or crash during go build after directories have already been marked as read-only. If the build server loses power or has a hard crash during go build then no error handling code will be able to run the chmod command.

We're using GitLab CI which unconditionally uses git clean after checkout to remove old build files. There's no option to add commands between the checkout and the clean.

[bcmills]

We're using GitLab CI which unconditionally uses git clean after checkout to remove old build files. There's no option to add commands between the checkout and the clean.

Wait, why is your module cache in the same git repository as the thing you're testing in CI? That seems like a very unusual configuration, and if you split the two it would be a lot easier to decouple the go clean -modcache or chmod from the go build or git clean step.

[Psykar]

@bcmills In my case at least it's not - buildroot (for example) build's it's output in a subdirectory of the repo however (which is under .gitignore)
Builds need to be reproducable without relying on any system packages (part of the build process will download golang source, compile and install it to a subdirectory, then use this installation for compiling the actual go packages which trigger this issue)

Having the module cache exist outside of the build directory means the build can potentially be affected by code outside of the repository.

For CI to a certain extend I agree that having the module cache actually be cached across builds makes a certain amount of sense.
But for buildroot (and similar) use case it does not.

FWIW the other side of the fence doesn't want to have to add a new command to their Makefile's specifically to handle a single package (golang) doing this.
http://lists.busybox.net/pipermail/buildroot/2019-April/248069.html

I'd like to find somewhere in the middle if possible!

[rsc]

This has come up enough that I think we should do something. There are good reasons for the default, but there are good reasons to be able to override it too. I suggest -pkgmodrw. CI systems can do things like export GOFLAGS=-pkgmodrw before their usual go commands.

/cc @bcmills @jayconrod

[bcmills]

I'm a little reluctant to put -pkgmod right there in the flag name, since it's conceivable that we'll want to move the package cache somewhere (outside of GOPATH?) in a future release.

That said, I'm still not sure why export GOFLAGS=-pkgmodrw is particularly better than go clean -modcache: either way, you end up needing to inject some sort of declaration at the start of the build.

[bcmills]

@jasonkeene, as noted in #31481 (comment) I think the execution bit is an easier win. Would you mind filing a separate issue for that?

[bcmills]

Regarding the flag name: I would prefer something that does not assume that the path to the module cache always contains the string pkg/mod. At some point, we may want to change the location of the module cache or make it configurable (as in #34527).

So I would really rather we find a name other than -pkgmodrw.

How about -modcacherw, or perhaps -modcachemask=0777?

[rsc]

-modcacherw is fine. Let's not bring Unix mode bits into this.

[gopherbot]

Change https://golang.org/cl/202079 mentions this issue: cmd/go: add a flag to avoid creating unwritable directories in the module cache

[zx2c4]

Thank you for working on this. Having to chmod things is indeed a huge hassle and sometimes not available in all build systems.

Does this mean I'll need to pass -modcacherw to both go get and go build invocations, just in case the latter invokes the former? If so, would we be better served by making this nob into an environment variable?

[thepudds]

If so, would we be better served by making this nob into an environment variable?

My expectation/ guess is export GOFLAGS=... would work for you once this is merged:

https://golang.org/cmd/go/#hdr-Environment_variables

[bcmills]

Exactly: we expect that it will generally be used in conjunction with GOFLAGS.

[gopherbot]

Change https://golang.org/cl/202563 mentions this issue: cmd/go: support -modcacherw in 'go mod' subcommands