-
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/doc: support 'go doc package@version' syntax #63696
Comments
That sounds like an awful lot of magic. 😅 For the specific case of printing a version in a usage string, perhaps we could provide a helper function somewhere that uses Or, perhaps |
FWIW, I wrote a module which looks at runtime/debug.ReadBuildInfo for CLI usage screens, but it would be nicer to have it built in somewhere. |
This proposal has been added to the active column of the proposals project |
Sounds like this is a likely accept, but the implementation will probably be tricky, so let's leave it for Go 1.23. |
I don't think we discussed whether it is possible to add
and this would be rejected:
After more discussion with @bcmills, I've realized that making this change the right way is going to require significant reworking of the existing machinery. Please don't send CLs. We'll take care of it. Thanks. |
Based on the discussion above, this proposal seems like a likely accept. go doc would change to accept an
|
No change in consensus, so accepted. 🎉 go doc would change to accept an
|
The
go doc
command displays documentation for packages in the workspace, but it would be very useful if it also worked on packages (and commands in particular) that are not part of the workspace, using an@version
suffix. The implementation would consult the module cache, populating it as needed. For example:@rsc made the suggestion that the version suffix could be inferred if the package name was not part of the workspace, if it matched the name of a command on
$PATH
, and that command was a Go executable, and the metadata inside that Go executable provided amodule@version
provenance string.The text was updated successfully, but these errors were encountered: