I'm working on a project that has no Go package in the root directory of the module. Running go get -u in the root results in
go get .: path $pkgpath is not a package in module rooted at $pkgpath
go help get states both
If an argument names a module but not a package (because there is no
Go source code in the module's root directory), then the install step
is skipped for that argument, instead of causing a build failure.
For example 'go get golang.org/x/perf' succeeds even though there
is no code corresponding to that import path.
With no package arguments, 'go get' applies to Go package in the
current directory, if any. In particular, 'go get -u' and
'go get -u=patch' update all the dependencies of that package.
With no package arguments and also without -u, 'go get' is not much more
than 'go install', and 'go get -d' not much more than 'go list'.
This seems to imply, to me, that running go get -u in the root of module with no package in that root shouldn't fail, especially not with such an unclear error. Maybe it would make more sense to have an error that states explicitly how to, for example, update all of the module's dependencies, which is likely what someone running go get -u in the module root without a package is trying to do.
The text was updated successfully, but these errors were encountered:
@abemotion That doesn't seem much clearer than the current message.
The intent here is most likely to update dependencies for all packages in the main module, rather than the package at the root of the main module. So, specifically if 1) . is the only argument, 2) the working directory is the same as the module root directory, and 3) -u or -u=patch is set, we could print a hint after the error message:
go get: run 'go get -d -u ./...' to update the main module's dependencies