-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: identify tool dependencies in go list / go mod why #70582
Comments
I noticed something a bit unintuitive while looking at #27719:
|
@seankhliao Could you give an example of the tools in the main module being ignored? |
With just this file:
results in
Which seems inconsistent with how it handles other tools (I would have expected either consistently no packages matched, or an error saying it has insufficient information about with an external tool
|
cc @ConradIrwin Since the tool directive implies an import of the tool package, I think we should be producing an error similar to an ImportMissingError. With these files:
So in the example above we'd want the following:
edit: it might be a bit annoying to add the go.mod:6:4 part so maybe we just print the importmissingerror |
Change https://go.dev/cl/634155 mentions this issue: |
I've sent a CL for the missing error in I think the behavior of I'm not sure what to do about I think we could either (in order of preference):
I think (3) is problematic because it makes parsing the output needlessly harder; I think (2) is a more reasonable compromise: it's clear to human readers, and parsers only need to be ok getting a meta-pattern instead of the package path. That said, the current behavior seems reasonable to me, so maybe (1) is the best option? |
Reopening this until we have a decision on If we weren't worried about breaking tools that invoked go mod why, I'd suggest something like this:
where we indicate the module that "imported" the tool on the line for the tool in the import stack. One thing we could consider for go mod graph is that it returns a one line parenthesized statement if the module isn't referenced from the main module. from go help mod why:
Perhaps we could do something similar to option 2, but instead of specifying tool we'd say that the package
Tools invoking But I think if we do go with an option other than option 1, we should specify the module that requires the tool to clarify where the tool comes from in the case of workspaces. |
Go version
go version devel go1.24-f8dba5f8c1 2024-11-23 01:01:47 +0000 linux/amd64
Output of
go env
in your module/workspace:What did you do?
go list -json honnef.co/go/tools/cmd/staticcheck
go list -m -json honnef.co/go/tools
A tool dependency shows no relation to the main module
Compared to a direct dependency
But it is listed as a dependency edge in the module graph:
What did you see happen?
I think tool dependencies are not consistently represented in
go mod graph
,go mod why
,go list
output.And there's no way to identify whether a package / module is a tool dependency (except maybe checking against
go list tool
).What did you expect to see?
Not sure if it should be consistently directly linked or detached from the main module.
And some attribute in the package to identify it being pulled in as a tool.
The text was updated successfully, but these errors were encountered: