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: separate subcommands into tool-facing vs user-facing? #29880

Closed
josharian opened this Issue Jan 23, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@josharian
Copy link
Contributor

josharian commented Jan 23, 2019

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

@josharian josharian added this to the Unplanned milestone Jan 23, 2019

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Jan 23, 2019

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

This comment has been minimized.

Copy link
Member

mvdan commented Jan 23, 2019

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

This comment has been minimized.

Copy link
Contributor Author

josharian commented Jan 23, 2019

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.

@josharian josharian closed this Jan 23, 2019

@mvdan

This comment has been minimized.

Copy link
Member

mvdan commented Jan 23, 2019

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment