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

proposal: go/build: export functionality for finding and quering go.mod information #34173

oakad opened this issue Sep 8, 2019 · 5 comments


Copy link

oakad commented Sep 8, 2019

When designing build automation tools a common list of queries usually arises:

  1. What is the current module name?
  2. Where's the module root (go.mod) is located?
  3. What the current module depends on?

All this information can be obtained relatively easily with a bit of (unstable) hackery.

However, it will be substantially more convenient if all this information was simply available from go standard library, which has all the useful tools implemented in internal/modload package and friends.

In particular, build.Context feels just like the right place to expose the above functionality to interested users.

@odeke-em odeke-em changed the title Export functionality for finding and quering go.mod information proposal: go/build: export functionality for finding and quering go.mod information Sep 8, 2019
@gopherbot gopherbot added this to the Proposal milestone Sep 8, 2019
Copy link

odeke-em commented Sep 8, 2019

Thank you for this proposal @oakad and welcome to the Go project!

I have updated the issue title accordingly and the proposal review committee shall take a look at it in the coming days/weeks and others shall chime in as they gather inputs.

Copy link

The (accepted) proposal for exposing mod file capabilities in a package was #31761
That proposal explicitly says that the kinds of things asked for in this proposal should not be in a package, the go command should be your interface for those.
The three specific queries you mention (if I understand what you are asking for) are
go list -m
go env GOMOD
go list -m all

go/build is deprecated in favor of go/packages, so we are very unlikely to add anything for modules to it, even if we were going to expose this in a package.

Copy link

oakad commented Sep 10, 2019

Using go command is less than ideal when dealing with build time code generators.

Instead of simply invoking few friendly API calls and catching any major stdlib changes in compile time, one has to operate os/exec: resolve paths, decide, in non-trivial fashion, which go compiler to use (if several are present), parse the output of child processes which may change subtly between go revisions and stuff like that.

This all constitutes "unstable hackery", as referenced in my issue submission. :-)

In fact, that whole process is lame enough as to warrant the modload re-implementation in custom 3rd party modules, go.mod parsing included.

Copy link

Using cmd/go as an API means that we can provide a stable API surface that will work across multiple Go versions. There is no reasonable way to do that if code to parse the go.mod file is linked into the binary. That means that an old binary is unlikely to be able to read new go.mod files. But the cmd/go API can easily remain the same.

In general the package is intended to provide a stable progammatic API, one that invokes cmd/go behind the scenes for you. It is likely that go/packages will move into the standard library when its API is considered stable.

Closing because there is no plan to provide this information in go/build.

Copy link

oakad commented Sep 10, 2019

I just want to note that I never asked for go/build explicitly, just merely used it as an example. I personally, don't have any preference as long as this functionality is present somewhere in the stdlib.

@golang golang locked and limited conversation to collaborators Sep 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

5 participants