cmd/go: module 0400 permissions are annoying #28137
Labels
FrozenDueToAge
modules
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
Comments
ALTree
changed the title
ALTree
added
modules
NeedsDecision
|
Does |
|
Probably, but that misses the point: most of the time I don't really have control over how temporary/intermediate build tree is cleaned up. A parent build system is responsible for that. Here's another example: imagine a Jenkins setup where I don't have any place to persist files in between builds and where the whole tree is supposed to be trivially clearable after builds. Again in this case, the 0400 permissions go sets are super annoying. Hence, a desire for some means of suppressing this. |
|
This was intentional. See @rsc's comment here - #27455 (comment). There is a duplicate bug which tracks slight improvements on this #27161. Feel free to add your suggestions there. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I use
go buildas part of larger build systems, such as gradle, xcodeproj, and cmake. In these cases, I'm generally putting various artifacts into a predefined build directory that I don't control. I'm only allowed to write files there, and so that's where they go. So, for example, downloaded go modules go into this intermediate/temporary build structure.When it's time for the parent build system to clean up its various temporary or intermediate directories, it of course chokes when hitting the 0400 directories. It's not very pleasant or clean (in error paths) to have to unconditionally run
chmod -fR +w .../pkg/modeverytime that eithergo buildorgo getis called.Rather, would you consider adding an option to these tools or perhaps even an environment variable that doesn't chmod anything and just uses the ordinary boring file permissions?
The text was updated successfully, but these errors were encountered: