Remove build dependency on golang

[codefromthecrypt]

Title: Remove build dependency on golang

Description:
While marketed as always compatible, recent versions of go break especially around how modules work. Rather than embed this problem into Envoy, causing other tensions like go's platform matrix, could we not depend on go? At least for release builds?

These are the files I can see that reference go source. There may be some incidental dependencies on go binaries I'm not aware of, but perhaps could be handled differently or isolated from a release.

./generated/docs/_downloads/ef307e1c6786b51ee38110d4bc3a839b/resource.go
./examples/dynamic-config-cp/resource.go
./examples/ext_authz/auth/grpc-service/main.go
./examples/ext_authz/auth/grpc-service/pkg/auth/users.go
./examples/ext_authz/auth/grpc-service/pkg/auth/v3/auth.go
./examples/load-reporting-service/server/lrs_server.go
./examples/load-reporting-service/main.go
./examples/grpc-bridge/server/service.go
./api/test/build/go_build_test.go

Relevant Links:

Homebrew/homebrew-core#83413 - go 1.17 upgrade of homebrew. Even if it is a red herring, even having someone validate if envoy build works or not costs them hours for the build to complete or fail. Removing the need to think about go, would save a lot of ecosystem time.

[ggreenway]

golang is needed to build/test BoringSSL.

[lizan]

It is not possible to remove build dependency as it is required to build BoringSSL. What's the issue are we trying to solve by that? The specific version of Go is pulled by Bazel and it's not affected by what is on the system.

[codefromthecrypt]

The problem to solve is coupling and time loss around go. The idea is if there's another way to accomplish the same goal we wouldn't have the distractions like the current inability to build arm64 Homebrew/homebrew-core#83413 (comment) (at least the go related distraction)

The more dependencies, the more problems and since the build takes an extremely long time, it occupies a lot of people to constantly run into problems.

[codefromthecrypt]

an option, not sure how relevant, could either be to vendor (extract as a dep instead of relying on system go), or to do the boringssl part inside docker (if that's possible or a relevant suggestion no idea)

[lizan]

an option, not sure how relevant, could either be to vendor (extract as a dep instead of relying on system go), or to do the boringssl part inside docker (if that's possible or a relevant suggestion no idea)

Again, we don't rely on system Go, it is pulled by Bazel here: https://github.com/envoyproxy/envoy/blob/main/bazel/dependency_imports.bzl#L14

[codefromthecrypt]

I don't know who originally wrote the formula (didn't bother to look), but probably they didn't know this didn't need system go. I raised a PR to remove it, which will prevent envoy from holding up homebrew's go formula Homebrew/homebrew-core#84071 Homebrew/homebrew-core#84072

The remaining topic of go being a heavy dep and possibly there's another way to consume boringssl in a more decoupled way vs building from source here, that's up to the team to decide to investigate or dismiss.

[keith]

@lizan isn't that what I was asking about the other day? It is listed as a build time dependency in the docs as well.

[lizan]

we should update docs then.

[codefromthecrypt]

among other things, the docs say to do some manual verification using go like below. As last time I tried to update a doc it took over a month with tons of revisions, I would appreciate if someone with commit access reviews and corrects on own.

Ex. from bazel/README.md

1. Install Golang on your machine. This is required as part of building BoringSSL
   and also for Buildifer which is used for formatting bazel BUILD files.
2. go get -u github.com/bazelbuild/buildtools/buildifier to install buildifier. You may need to set BUILDIFIER_BIN to $GOPATH/bin/buildifier
   in your shell for buildifier to work.
3. go get -u github.com/bazelbuild/buildtools/buildozer to install buildozer. You may need to set BUILDOZER_BIN to $GOPATH/bin/buildozer
   in your shell for buildozer to work.

[moderation]

I've been building Envoy on MacOS for years and have builds working on M1 now. The only patch for this to work with M1 now is Bazel. The Go part of fine.

Similarly have been building for years in aarch64 (Raspberry Pi). In the early days of aarch64 the were architecture teething issues with Go and Bazel. But they were all fixed upstream and have been working for years.

The specific campaign to "remove Go" seems to be related specifically to Homebrew. As per above there isn't a problem with Go. Can Homebrew be fixed?

[codefromthecrypt]

@moderation the below did happen and it did say problem downloading go, and it only happened on arm64

==> /opt/homebrew/opt/bazelisk/bin/bazelisk build --compilation_mode=opt --curses=no --show_task_finish 
Last 15 lines from /Users/thebots/Library/Logs/Homebrew/envoy/01.bazelisk:
ERROR: An error occurred during the fetch of repository 'go_sdk':
   Traceback (most recent call last):
	File "/private/tmp/envoy-20210827-59011-735pgh/.brew_home/_bazel/6734651a1108d63ae9e743df04c9a20c/external/io_bazel_rules_go/go/private/sdk.bzl", line 98, column 13, in _go_download_sdk_impl
		fail("unsupported platform {}".format(platform))
Error in fail: unsupported platform darwin_arm64
ERROR: Error fetching repository: Traceback (most recent call last):
	File "/private/tmp/envoy-20210827-59011-735pgh/.brew_home/_bazel/6734651a1108d63ae9e743df04c9a20c/external/io_bazel_rules_go/go/private/sdk.bzl", line 98, column 13, in _go_download_sdk_impl
		fail("unsupported platform {}".format(platform))
Error in fail: unsupported platform darwin_arm64
ERROR: Analysis of target '//source/exe:envoy-static' failed; build aborted: unsupported platform darwin_arm64
INFO: Elapsed time: 83.843s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (18 packages loaded, 7 targets configured)
FAILED: Build did NOT complete successfully (18 packages loaded, 7 targets configured)

Whether or not you (an expert) are able to have a perfect working environment isn't the motivation of this issue. It is if the distraction caused by go and there have been, not just this one, is a required distraction or an optional one.

I can already tell you are in favor of keeping it, but let's not pretend everyone else's experiences and time loss never happened

[codefromthecrypt]

PS it is a good point to try to fix homebrew #17500 hopefully can switch things to ad-hoc after the fact fixes to proactive part of a release. You'd get less non-experts commenting issues like this if the project team owned all their releases.

[mattklein123]

I'm going to close this out as this is not going to realistically happen.

You'd get less non-experts commenting issues like this if the project team owned all their releases.

In a world of infinite resources this sounds great. We don't live in such a world. Help appreciated.