cmd/go: define command-line API for tools

[mvdan]

As per discussion in #18653.

https://github.com/kisielk/gotool has existed for quite some time as a way for external tools to be able to resolve import paths such as . and ./.... See its godoc: https://godoc.org/github.com/kisielk/gotool

This functionality is implemented in cmd/go but it's not exported and available to Go programs, so gotool does exactly that - it copies the source code and makes it available in an importable package.

@rsc mentions that external tools should instead depend on the go executable:

There is no intent to expose the internals of the go command for direct import by programs that want to behave like it. I would prefer if those programs invoked the go command to find out what they need to find out: the API is the binary itself, not the Go package. Using the binary means that when some detail of the go command changes, all those other tools don't need to be updated. I'd be happy to talk about what those tools need.

I assume ImportPaths would be replaceable by go list in most scenarios.

This issue exists to figure out if the command-line tool needs any changes to accomodate for the gotool use case.

cc @kisielk who wrote the package
cc @mdempsky @dominikh @shurcooL @davecheney @FiloSottile who use the package (aside from myself)

[mvdan]

Ignoring @rsc's comment for a second, my initial thought as an external tool developer is that using the go executable would have a couple of drawbacks:

• The tool now depends on go being available and being the same Go version as the external tool (or at least compatible)
• Boilerplate code is needed to do the command execution and parse its output (going from a one-package-per-line stdout to []string, for example)

Those two can be taken care of in the external tool, but the whole point of gotool is to minimize code duplication and margin for error.

[dmitshur]

This issue exists to figure out if the command-line tool needs any changes to accomodate for the gotool use case.

As someone who relies on and helps maintain gotool, I don't think you need to worry about this. We'll take care of accommodating for any changes in cmd/go.

I highly prefer to import a pure Go library in order to achieve go list functionality than try to execute go binary. I've read Russ's #18653 (comment) and I understand his POV. I think he's saying that "by default, use the binary, doing that is supported by us, anything else is not; however, if you're willing to spend more effort maintaining a library that copies the code, we can't stop you". I am happy to maintain gotool so that I can continue to use it, and I'll gladly update it if needed to achieve parity with cmd/go. It's not very hard.

The gotool package is a little like unsafe. You shouldn't create/maintain it unless you know what you're doing and willing to deal with the consequences.

[bradfitz]

@mvdan, @shurcooL, what's the status of this bug?

[dmitshur]

This issue came to exist because of the following exchange in #18653:

rsc: There is no intent to expose the internals of the go command for direct import by programs that want to behave like it. I would prefer if those programs invoked the go command to find out what they need to find out: the API is the binary itself, not the Go package. Using the binary means that when some detail of the go command changes, all those other tools don't need to be updated. I'd be happy to talk about what those tools need.

mvdan: this sounds like a good idea. Should I open a separate issue and ping people who'll probably be interested?

rsc: Sure, please open a new issue 'cmd/go: define command-line API for tools' and please list there the kinds of things your tools need to find out from the go command. Thanks.

And, as this issue says:

This issue exists to figure out if the command-line tool needs any changes to accomodate for the gotool use case.

From the discussion here so far, as far as I can tell, the answer is that nothing in cmd/go needs to change.

So it can be closed.

[bradfitz]

Thanks. SGTM.

[mvdan]

I agree that it seems like there's nothing to do - the cmd/go bits won't be importable anytime soon, and some people in the community are happy to keep a copy of some of its code separately.

I was keeping this issue open to see if @rsc had anything to add or comment, since he was the one who proposed opening this issue.