Temporarily remove private/usage restrictions and do 1.1.1 release #1013
Labels
Bug
Something isn't working
Comments
lrewega
added a commit
that referenced
this issue
Mar 21, 2022
A change introduced in go 1.18, [CL 339170][0], altered `runtime/debug.BuildInfo` details for the `command-line-arguments` pseudo-package, which represents file arguments provided to tools such as `go build` or `go run`. As such, it's no longer possible to determine the package name associated with the `main` function when the file it's defined in is passed as a file argument. Let's avoid `command-line-arguments` altogether by changing how we build binaries, instead referring to `main` packages using package path syntax. Now that we can determine the package path of the `main` function again, re-introduce invoking `private/usage.check` in `private`'s `init()`. See also #1013 and bufbuild/homebrew-buf#8 [0]: https://go-review.googlesource.com/c/go/+/339170/
lrewega
added a commit
that referenced
this issue
Mar 21, 2022
A change introduced in go 1.18, [CL 339170][0], altered `runtime/debug.BuildInfo` details for the `command-line-arguments` pseudo-package, which represents file arguments provided to tools such as `go build` or `go run`. As such, it's no longer possible to determine the package name associated with the `main` function when the file it's defined in is passed as a file argument. Let's avoid `command-line-arguments` altogether by changing how we build binaries, instead referring to `main` packages using package path syntax. Now that we can determine the package path of the `main` function again, re-introduce invoking `private/usage.check` in `private`'s `init()`. See also #1013 and bufbuild/homebrew-buf#8 [0]: https://go-review.googlesource.com/c/go/+/339170/
Monirul1
pushed a commit
to Monirul1/buf
that referenced
this issue
Apr 30, 2023
A change introduced in go 1.18, [CL 339170][0], altered `runtime/debug.BuildInfo` details for the `command-line-arguments` pseudo-package, which represents file arguments provided to tools such as `go build` or `go run`. As such, it's no longer possible to determine the package name associated with the `main` function when the file it's defined in is passed as a file argument. Let's avoid `command-line-arguments` altogether by changing how we build binaries, instead referring to `main` packages using package path syntax. Now that we can determine the package path of the `main` function again, re-introduce invoking `private/usage.check` in `private`'s `init()`. See also bufbuild#1013 and bufbuild/homebrew-buf#8 [0]: https://go-review.googlesource.com/c/go/+/339170/
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See bufbuild/homebrew-buf#8
See golang/go#51831
There's no immediately apparent workaround here - unless this is fixed, we can't use this technique anymore. We need to make sure homebrew builds aren't broken, so we should temporarily remove the
check()call ininit()and do a micro release.The text was updated successfully, but these errors were encountered: