proposal: cmd/go: Declare module content in
A typical non-trivial repository with a Go module contains files/directories that don't need to be packaged into the module and distributed with the code, such as:
It would be ideal to have a fine-grained control on what gets included into the module content. Currently, there are workarounds:
Approach (1) is not universal, and requires remembering the exceptions, which is an unnecessary cognitive load.
Approach (2) is more complete, but is less convenient at scale. It also does not allow an easy way to have a consolidated view of the included/excluded paths.
More discussion here: #30058.
Introduce a top-level
The current (and the default, if
This format allows various approaches to controlling the content of the module:
The text was updated successfully, but these errors were encountered:
This makes go modules substantially less simple for seemingly very minor convenience gains. I guess I have a hard time sympathizing with the problem as you describe it, and would rather protect my simple understanding of go modules. Perhaps there’s something I’m not understanding about the importance of having a consolidated list of excludes?
@hherman1 Could you clarify what your simple understanding of Go modules is?
This mechanism would be optional (default = old behaviour), so the module author could still do the simple thing. In which way would it make Go modules more difficult for you?
One of the gains would be performance: excluding bulky/non-Go clutter from the module saves time and space on the dev machine, module proxy, and all the downstream dependencies (dependent modules, other developers machines, CI workflows).
Potential target auditory for this flexible configuration are the owners of complex repositories who can't necessarily do the simple thing, e.g. put all the Go code in a single directory. This includes projects started before Go modules / semver introduction, who did not account for this in the repository structure.
The addition of optional features still affects me even if I don’t personally use them because
I prefer uniformity over fragmentation where possible, and I can already foresee the complaints about “go modules are so confusing you have to read globs to figure out where it’s safe and not safe to write code”.
Also, it’s still not entirely clear to me how big the win here is over using the empty go.mod files you referenced.