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

[oakad]

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]

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.

[ianthehat]

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.

[oakad]

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.

[ianlancetaylor]

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 golang.org/x/tools/go/packages 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.

[oakad]

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.