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.

Sign up for GitHub

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: make 'cmd/internal/load' public #25998

Closed
nyarly opened this issue Jun 21, 2018 · 4 comments
Closed

cmd/go: make 'cmd/internal/load' public #25998

nyarly opened this issue Jun 21, 2018 · 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

@nyarly
Copy link

nyarly commented Jun 21, 2018

For a piece of build-related tooling, I recently had call to list the main packages within a source tree.
I was disappointed to discover that go list uses an internal package to perform this task, and therefore the code to list Packages isn't available for use outside of go itself.

I'd like to propose that at least a public-facing interface over cmd/internal/load be made available, since listing packages is a fundamental operation to development related tooling. T

he consequence of the load package not being available that either

  1. this task must be performed by shelling out to go list which means that that interface must be made safe for machine use (and also that errors in that task will only be discovered at runtime.)
  2. the code from the load package will be imitated (or copied), leading to balkanized buggy re-implementations over time.
@ianlancetaylor ianlancetaylor changed the title Make 'cmd/internal/load' public. cmd/go: make 'cmd/internal/load' public. Jun 21, 2018
@ianlancetaylor
Copy link
Member

Our general policy on this has been that the go tool itself is the API. To do this kind of operation, simply invoke the go tool. We don't want to have to maintain a library API.

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 21, 2018
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jun 21, 2018
@nyarly
Copy link
Author

nyarly commented Jun 21, 2018

I can appreciate that position, but in terms of building go tooling in go, the go tool then becomes a library API. Are the commands, their arguments and their output being treated as a software API?

Conversely, as I've dug in further, aspects of this tooling refer out e.g. to go/build so significant parts of the go tool machinery are being provided as a library API.

My immediate use case here is "what packages are available to import", which turns out to be a knotty problem. (My personal chestnut has to do with multple entries in the GOPATH.) Does it make sense for that task to get reimplemented?

@ALTree ALTree changed the title cmd/go: make 'cmd/internal/load' public. cmd/go: make 'cmd/internal/load' public Jun 21, 2018
@ianlancetaylor
Copy link
Member

The go tool is being used in various scripts, so in effect we are locked in to its general behavior. The go/build package was an idea that I think has not worked out all that well as ideas have moved forward.

I believe that the question of "what packages are available be import" is answered by

go list -f '{{.ImportPath}}' ...

@bcmills
Copy link
Contributor

bcmills commented Jan 18, 2019

golang.org/x/tools/go/packages provides programmatic access to go list. Beyond that, the command-line API of go list is relatively stable at this point.

@bcmills bcmills closed this as completed Jan 18, 2019
@golang golang locked and limited conversation to collaborators Jan 18, 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
@nyarly @ianlancetaylor @bcmills @gopherbot