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

Open
nyarly opened this Issue Jun 21, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@nyarly

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 from Make 'cmd/internal/load' public. to cmd/go: make 'cmd/internal/load' public. Jun 21, 2018

@ianlancetaylor

This comment has been minimized.

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.

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 from cmd/go: make 'cmd/internal/load' public. to cmd/go: make 'cmd/internal/load' public Jun 21, 2018

@ianlancetaylor

This comment has been minimized.

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}}' ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment