-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: cmd/go: Declare module content in go.files
config
#52807
Comments
go.files
configgo.files
config
see also #42965 |
go.files
configgo.files
config
This proposal has been added to the active column of the proposals project |
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. |
This seems like a duplicate of #42965. Neither seems particularly likely given past discussions. |
This proposal is a duplicate of a previously discussed proposal, as noted above, |
Issue
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:
.
or_
, or namedtestdata
are excluded.go.mod
in a directory cuts this entire directory from the Go module it was in.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.
Proposal
Introduce a top-level
go.files
config (next togo.mod
and co) which represents the consolidated view of the Go module content. The file consists of include/exclude rules/globs/regexps, in order of their priority. This would be similar in semantics to .gitignore. For example, it can look like this:The current (and the default, if
go.files
is not present) behaviour would be described by a file like this:This format allows various approaches to controlling the content of the module:
Another example:
The text was updated successfully, but these errors were encountered: