-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: allow 'go mod tidy' to proceed despite errors #26603
Comments
There's a significant example of this that I encountered recently when using TinyGo. TinyGo has some additional packages in its standard library (for example, the "machine" package). Because those packages don't exist in the regular Go standard library, Here's a testscript example to demonstrate the issue:
The go command fails with this error:
|
@rogpeppe, do the TinyGo source files have a particular build constraint? If so, the narrower fix described in #40067 (comment) might be more appropriate. |
I showed a complete example above. No build constraints involved, I'm afraid. |
Then I would argue the defect in that example is in TinyGo, not If the program by all accounts indicates that it expects to be compiled in a standard |
FWIW there's no problem with using the standard go command for this code (I can happily Since one of the aims of For my particular problem, it seems to me that |
Unfortunately, that does not hold in the presence of |
You can use a replace directive to replace a stdlib package? Interesting. I had no idea. |
You can't use it to replace a package that actually exists in the standard library, but you can use it to slot in a module whose path would normally be reserved for the standard library (just like you can do by manually poking directories into a |
Change https://golang.org/cl/255960 mentions this issue: |
Change https://golang.org/cl/287413 mentions this issue: |
For golang/go#26603 Change-Id: I4bb1138ebda5ded1be30ead19bd6b282eedc3265 Reviewed-on: https://go-review.googlesource.com/c/website/+/287413 Trust: Jay Conrod <[email protected]> Reviewed-by: Bryan C. Mills <[email protected]>
When adding module definitions to existing repositories, we may (often?) find that one or more existing packages do not actually build, or that some import cannot be resolved due to a bug (e.g., #26602).
Failure to build is especially likely for files with rarely-used build constraints, but rarely-used constraints are exactly the space that
go mod -sync
scans.If the user needs to intervene to fix something, it would be nice if they could generate the rest of the module definition before they start trying to troubleshoot one or two packages that still won't build. For example, here is the output of
go mod -sync
forgolang.org/x/build
: it's a huge dependency graph, and seems to be held back by one missing import.The text was updated successfully, but these errors were encountered: