cmd/go: separate subcommands into tool-facing vs user-facing?

[josharian]

cmd/go has historically been user-facing.

Recently, we have started to lean on it more as the single source of truth about how the build and package management system works, moving away from package-based APIs like go/build.

This has caused non-trivial pain. One example: #29452 is about trouble with go list side-effects. Another example: folks are already moving away from using it in favor of copying and pasting code. There are more.

I wonder whether we should start to address these issues by adding specialized subcommands to cmd/go that aren't necessarily clean or pretty, but that instead are focused on efficiently addressing common tooling needs and that have guaranteed stable output and that have useful properties for tooling like being side-effect-free or network-access-free. The obvious analogy is git's porcelain vs plumbing, although those names are not great.

This is a vague suggestion; it is meant to provoke discussion and perhaps change how we're thinking about this set of problems.

cc @mvdan @heschik @bcmills

[bcmills]

The behaviors that are confusing for tool authors are also confusing for interactive users, so we should fix those behaviors for both, and we already have -json flags to toggle between human-readable and machine-readable output.

I certainly agree that we should address the areas that folks find confusing, but I think adding (or splitting) commands for tools would add more confusion than it resolves.

[mvdan]

If this is purely about side effects, I agree with Bryan.

If it's about speed, I think the regular commands should be made faster instead. See for example #29382 and #29758.

[josharian]

I think the regular commands should be made faster instead.

I'm mildly skeptical about this. From my limited understanding, go/packages is invoking go list multiple times because that is what is required to gather all the information it needs. Analogy: REST APIs vs GraphQL APIs.

Anyway, I'm happy to keep going down the current path for now. I was just pretty discouraged and alarmed to see go/imports abandon go/packages so soon. (Although I'm happier that it is faster.)

Thanks, all, for the discussion.

[mvdan]

I was just pretty discouraged and alarmed to see go/imports abandon go/packages so soon.

Me too; see my comment on https://go-review.googlesource.com/c/tools/+/158097. The plan is to make goimports use go/packages again, sometime after 1.13 is out. If the go list packages driver is still not fast enough then, and we've run out of options, I presume you can raise this issue again :)