Skip to content
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

Jump to bottom

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

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

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

josharian opened this issue Jan 23, 2019 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@josharian
Copy link
Contributor

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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 23, 2019
@josharian josharian added this to the Unplanned milestone Jan 23, 2019
@bcmills
Copy link
Contributor

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
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
Copy link
Contributor Author

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

@golang golang locked and limited conversation to collaborators Jan 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@josharian @mvdan @bcmills @gopherbot