-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: "package not found" error is less useful than GOPATH's when the missing package could have been in the main module #37214
Comments
This line would be misleading: we would not even check that directory, because the first component of the missing import path contains a dot.
This one we can perhaps fix. (Compare #33568 (comment).) If we don't have any candidate modules to check in the first place, we produce an error message like:
(That comes from here.) And note that if
So probably we should mention the main module in some form here too. But we need to be careful about how we describe the file path, because it is entirely possible that |
Sure, I didn't mean to dictate any specifics. I was more arguing for a philosophy of error reporting: for each location looked up, there should be some variety of not found error, and if resolution eventually fails, the resulting message should detail each location searched and why it didn't work. So for the case at the end of your comment, I would hope for something like |
Also, I'd like to see the same thing for replace targets, not just the main module. |
Change https://golang.org/cl/185345 mentions this issue: |
This change is a non-minimal fix for #32917, but incidentally fixes several other bugs and makes the error messages much more ergonomic. Updates #32917 Updates #27122 Updates #28459 Updates #29280 Updates #30590 Updates #37214 Updates #36173 Updates #36587 Fixes #36008 Fixes #30992 Change-Id: Iedb26d2e0963697c130df5d0f72e7f83ec2dcf06 Reviewed-on: https://go-review.googlesource.com/c/go/+/185345 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Message seems now inline with expectations:
|
Given the following setup:
and then running:
This is clear and actionable: there are two directories that could have contained the package, and neither did. You can ls the directories, compare the paths to the filesystem, etc.
In module mode:
This is much less actionable. Why is it going to the Internet for a package that should be on the local filesystem? Did it look anywhere first, and if so where? (If example.com were a GitHub URL the error would be different, but talking about private repos isn't any more helpful here.)
In case it wasn't obvious, the problem is a typo: the package is named mypackage, not mypkg. I think the GOPATH error gives a new user a fighting chance of finding their mistake; the module error needs at least a basic understanding of package-to-module resolution, and nested modules (!) to make any sense.
Concretely, I would like to see the module mode error look more like the GOPATH error:
@bcmills @jayconrod
The text was updated successfully, but these errors were encountered: