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

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

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

Comments

Projects
None yet
3 participants
@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

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Jun 21, 2018

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.

@nyarly

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Jun 21, 2018

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

This comment has been minimized.

Copy link
Member

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 Jan 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.