Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: should 'go get path@version' (without '-m') report an error if 'path' is only a module? #29268
A Go module path is not necessarily a valid Go package path: for example,
On the other hand, if the user intends to pass a module path (rather than a package path), they can indicate that explicitly using the
Should we change the error-suppressing path to instead produce a non-zero exit code? We could still make the error explicit about the fact that the requested path is a module but not a package.
One comment on the current implementation: it seems a repo root that only has a
GO111MODULE=on go get k8s.io/api@master go: finding k8s.io/api master go: downloading k8s.io/api v0.0.0-20181130031204-d04500c8c3dd go build k8s.io/api: no non-test Go files in .../firstname.lastname@example.org
Module paths being the import path of the root directory of the module is just a fundamental design choice we've made (and are not going to unmake). That creates a little bit of ambiguity, which can easily lead to confusion. But some confusion will exist no matter what we choose here. The choice is what the confusion looks like.
In the world where go get module@version simply doesn't build code that isn't there (but still updates go.mod and therefore has a useful effect), users mostly ignore the distinction between module path and import path and they go on with their work. I think this is the best world; it's the one we're in now.
In the world where go get module@version succeeds when there is code in the root of the module but fails when there is not, we will get a steady stream of bugs complaining that some modules are compatible with 'go get without -m' while other modules are not, and people will be confused about why. Some people will learn to type 'go get -m' literally every time they run 'go get' (because downloads now happen automatically, the only time you really run 'go get' anymore is for manipulating modules). Other people will write blog posts explaining that best practice is to write dummy empty packages in the roots of your modules so that they work even when users forget to type -m. This seems to me a worse world. It has strictly more confusion for end users than the current world.
The k8s.io/api failure (only test go files in package) should be suppressed for all go get targets, not just the root of the module.
The particularly confusing behavior here for repos with major-version breaks that predate semantic import paths.
To draw an example from #27123: the module
The options are unfortunate either way:
This may be a corner case either way, since packages should not disappear in general, but there certainly are plenty for existing repos that behave this way.
The ambiguity occurs without
referenced this issue
Dec 28, 2018
Here is another neat example, from a conversation with @lopezator. The root of
The message is not