The API break change debug.ReadBuildInfo from 1.18

[Lee Baokun]

Hi,

Our internal infrastructure services rely heavily on the API:  debug.ReadBuildInfo()

and we updated to Go 1.18 recently, and this break change breaks our service.

but this change not listed in 1.18 release notes. 

I filed a issue, as Sean said: this working as intended, but anyone can help me why we choose this: command-line-arguments not as a module any more from 1.18

And should we updated the 1.18 release notes?

Best,

Baokun

[Bryan C. Mills]

On Mon, Dec 5, 2022 at 2:34 AM Lee Baokun <not...@gmail.com> wrote:

Hi,

Our internal infrastructure services rely heavily on the API:  debug.ReadBuildInfo()

and we updated to Go 1.18 recently, and this break change breaks our service.

but this change not listed in 1.18 release notes. 

I filed a issue, as Sean said: this working as intended, but anyone can help me why we choose this: command-line-arguments not as a module any more from 1.18

Partly, because the name of the package itself violates the usual module property that the module path (for all modules other than `std`) is a prefix of the package import path. We define a “module” as “a collection of packages that are released, versioned, and distributed together”, but the "command-line-arguments" package isn't released or versioned: it contains whatever files you happened to pass on the command line, not a well-defined set of files that is always the same for a given module version.

Partly, because it isn't included in the usual module operations. For example, source files tagged `//go:build ignore` can be used to create a command-line-arguments package, but wouldn't be included by `go mod tidy` or `go mod vendor`.

And partly, because the command-line-arguments package can be loaded from literally anywhere: if you're in a workspace containing three different modules, and you run `go build /tmp/foo.go`, which of those three modules contains `command-line-arguments`? We could make up an arbitrary answer, or try to find the containing module and fall back to “no module”, but given how oriented cmd/go is toward packages (as opposed to files) it seemed more consistent to always treat individual files passed on the command line as separate from the module.

And should we updated the 1.18 release notes?

Updating the release notes would be fine.

Best,

Baokun

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/88b8ad37-e33e-4088-b448-391d03b5941en%40googlegroups.com.