-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: go mod tidy, vendor hide module load errors #27063
Comments
#27868 is possibly a duplicate of this issue; I'm not positive. |
We have run into this issue where using We caught it because our CI system is now running |
Change https://golang.org/cl/153459 mentions this issue: |
Use the actual loader result in findModule instead of making assumptions about nesting in the build list. As a side-effect, this produces much clearer error messages for packages that (for one reason or another) failed to load. Adjust the package and module path outside a module to "command-line-arguments". That string already appears in the output of a number of (module-mode and GOPATH-mode) commands for file arguments, and as far as I can tell operation outside a module is currently the only case in which the module path of a package is not actually a prefix of the import path. Fixes #28011 Fixes #27099 Fixes #28943 Updates #27102 Updates #28459 Updates #27063 Change-Id: I61d5556df7b1b7d1efdaffa892f0e3e95b612d87 Reviewed-on: https://go-review.googlesource.com/c/153459 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
This might be another instance of this, I'm not 100% sure: The following:
gives no results. But if you then do:
you get:
which I think is as expected because:
|
@bcmills this issue is tagged with As context I think this is a quite important issue to solve before go1.13 as it adds a lot of confusion for users. I've seen several cases the thing that happens when |
Hi @leitzler or @jsternberg, I think |
Sure! So far I have three different cases that I think is directly caused by this issue.
|
@leitzler That's great! Thank you for taking the time to do that. |
We need to figure out which paths are missing the needed error checks, and how to add them without breaking things like |
FWIW I just ran across what I think was this issue when using |
Change https://golang.org/cl/188763 mentions this issue: |
The fix for this turned out to be super simple, given the nice import-stack reporting that @jayconrod added earlier in the 1.13 cycle. I'm hoping we can get this into the next 1.13 build. |
The module loader leaves some problems for the standard loader to find, like not being able to resolve imports. But 'go mod tidy' and 'go mod vendor' do not run the standard loader, so those problems go undiagnosed. Maybe we should look for them explicitly.
For example make a file x.go that says import "nonexist". go mod tidy succeeds quietly.
The text was updated successfully, but these errors were encountered: