Skip to content
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

cmd/go: clarify error message for 'go get -u' without arguments in a module root that is not a package #37700

Open
DeedleFake opened this issue Mar 5, 2020 · 6 comments
Labels
Documentation modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@DeedleFake
Copy link

What version of Go are you using (go version)?

go version go1.14 darwin/amd64

What did you do?

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.

and

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.

@bcmills
Copy link
Contributor

bcmills commented Mar 6, 2020

go get without arguments is equivalent to go get .
And the argument . does not name a module.

~/go/src$ go list -m .
go: cannot use relative path . to specify module

If you want to update the dependencies of all packages within a module, you want go get -u -d ./....

We probably do need a clearer error message for this case.

@bcmills bcmills added modules NeedsFix The path to resolution is known, but the work has not been done. labels Mar 6, 2020
@bcmills bcmills added this to the Backlog milestone Mar 6, 2020
@bcmills bcmills changed the title cmd/go: error message for update in packageless module root seems to contradict documentation cmd/go: clarify error message for 'go get -u' without arguments in a module root that is not a package Mar 6, 2020
@bcmills
Copy link
Contributor

bcmills commented Mar 6, 2020

CC @jayconrod @matloob

@abemotion
Copy link

https://golang.org/src/cmd/go/internal/modget/get.go#L342

go get .: no matching packages in module rooted at $pkgpath

How is this error message ?

@jayconrod
Copy link
Contributor

@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

@abemotion
Copy link

@jayconrod Thank you for your polite reply 😊

Your message is much clearer than my comment's one that doesn't have a hint.

@mieubrisse
Copy link

+1 to a clearer error message - even something like use go get ./... to scan for modules in subdirectories would help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants