go doc 命令显示工作区中软件包的文档，但如果它也能在不是工作区的软件包(尤其是命令)上使用 @version 后缀，那就非常有用了。实现方式是查询模块缓存，根据需要填充它。例如：
$ go doc go.starlark.net/syntax@latest
go: downloading go.starlark.net v0.0.0-20231016134836-22325403fcb3
go: added go.starlark.net v0.0.0-20231016134836-22325403fcb3
package syntax // import "go.starlark.net/syntax"
Package syntax provides a Starlark parser and abstract syntax tree.
...@rsc 建议，如果软件包名称不是工作区的组成部分，且与 $PATH 上的命令名称匹配，该命令是 Go 可执行文件，且该 Go 可执行文件内的元数据提供了 module@version 来源字符串，则可以推断出版本后缀。
7条答案
按热度按时间nwsw7zdq1#
如果包名不是工作区的一部分，且与
$PATH上的命令名称匹配，且该命令是Go可执行文件，并且该Go可执行文件内的元数据提供了一个module@version来源字符串，那么可以推断出版本后缀。这听起来像是很多魔法。😅
对于在用法字符串中打印版本的特定情况，也许我们可以在某个地方提供一个辅助函数，该函数使用
runtime/debug.ReadBuildInfo为当前二进制文件生成一个path@version字符串？这可以用于用法消息和--version标志，这样用户就可以运行类似go doc $(syntax --version)的操作。或者，也许
go version本身应该有一个标志来打印这种形式？这样用户就可以运行go doc $(go version -main $(which syntax))了。xeufq47z2#
对于在用法字符串中打印版本的特定情况，也许我们可以在某个地方提供一个辅助函数，该函数使用runtime/debug.ReadBuildInfo来生成当前二进制文件的路径@版本字符串？这可以用于用法消息和--version标志，以便用户可以运行类似于go doc $(syntax --version)的操作。
顺便说一下，我为CLI用法屏幕编写了a module which looks at runtime/debug.ReadBuildInfo,但将其内置到某个地方会更好。
wlzqhblo3#
此建议已添加到建议项目中的活动列，并将在每周的建议审查会议上进行审查。
— rsc 建议审查组
piv4azn74#
这听起来是一个可能的接受，但实现可能会很棘手，所以让我们把它留到Go 1.23。
vbkedwbf5#
我认为这两个应该可以：
这个会被拒绝：
在与@bcmills的更多讨论后，我意识到以正确的方式进行这种更改将需要对现有机制进行重大修改。请不要发送CL。我们会处理好的。谢谢。
f4t66c6m6#
根据以上讨论，这个建议看起来像是很有可能被接受。
— rsc(建议审查组)
go doc将更改为在其第一个参数上接受一个
@version后缀，因此这些都变得有效：hsgswve47#
共识没有变化，所以接受。🎉
这个问题现在跟踪实施提案的工作。
— rsc,提案审查组
go doc将更改为在其第一个参数上接受一个
@version后缀，因此这些都变得有效：