Looks like there are 291 formula that still use GOPATH.

While we're here - would it be worth standardizing some of the flags that we use for building Go formulae? Specifically, I would advocate for always including

• -ldflags "-s -w", unless it breaks build
• -trimpath: "remove all file system paths from the resulting executable. Instead of absolute file system paths, the recorded file names will begin with either "go" (for the standard library), or a module path@version (when using modules), or a plain import path (when using GOPATH)."

It looks like Debian sets -trimpath but doesn't strip binaries with -s -w. Would it be useful to add something like std_go_args (like we have for CMake builds)?

Would it be useful to add something like std_go_args (like we have for CMake builds)?

I think it would be useful. I've already seen some formulae floating around with stripped binaries, which is why I've brought this up. From my limited testing with the PRs above, there's a reduction of 15-20% in total formula size. I personally don't think it would be a bad idea to strip binaries, seeing as Go binaries are all statically linked.

Maybe you want to wait @chenrui333 and do gopath at the same time as the go_std_args?

Would it be useful to add something like std_go_args (like we have for CMake builds)?

+1 for std_go_args idea.

We can definitely pipeline the work between std_go_args and gopath removal though.
After that we can refine our template for easy bootstrap golang formula.

All right! we are all done ( i think). We have PRs for all the tools listed in @carlocab's comment.

While we have filed issues with a LOT of the tools there I doubt that many of them will actually upgrade to go modules by the time go1.17 is out. Would the idea be to deprecate them or disable them or add a go1.16 formula when that time comes?

Possibly both - we could deprecate as "unmaintained" if there is no response, but we'll let them depend on go@1.16 for that deprecation period.

I'm very likely going to start tests with 1.17 RC1 when that lands rather than the final version so that we're better prepared.

For 1.16: we just now need to double check a couple of the other failures but they should be easy to prove they are pre-existing or not and then we can rebase on master (with the bootstrap change we agreed on in #71370 (comment)).

Thanks very much for all the help, @roopakv. There are still a handful of formulae that don't use GOPATH but nevertheless did failed with go1.16: #71289 (comment)

Is this still a problem with current Go versions?

It generally is not a problem (using GOPATH was never broken across the board, just in some corner cases like we've seen in the past); however usage of modern Go modules is definitely preferred. I would consider this on par with a style issue since I don't foresee Go fully disabling the deprecated functionality.

I may make one more pass through the list and post remaining items as a comment (for posterity). We can continue working on it if preferred or close this soon.

Upstream HEAD has module support but has not landed in a release

• ahoy
• apache-brooklyn-cli
• aptly
• devd
• dockerize
• goofys
• gx-go
• jabba
• pup
• textql

Upstream is still not using modules yet

• amazon-ecs-cli
• ccat
• confd
• docker-machine-driver-vultr
• dockviz
• dockward
• emp (Compatibility with future Go versions remind101/empire#1167)
• flint-checker
• forego
• gdm
• github-release
• go-bindata
• jp
• launch_socket_server
• mailhog
• massren (support go modules for go 1.16 or brew will soon stop being able to build massren laurent22/massren#44)
• qpm
• rack
• sift
• snag
• termshare
• uru

Upstream is still not using modules yet (deprecated/disabled)

• cf-tool
• corectl
• cosi
• cwlogs
• dep
• docker-machine-driver-hyperkit
• docker-machine-driver-xhyve
• docker-machine
• docker-swarm
• docker2aci
• fleetctl
• glide
• go@1.13
• go@1.14
• goad
• gofabric8
• govendor
• grv
• helm@2
• infrakit
• ironcli
• kedge
• landscaper
• modd
• mpdviz
• rancher-compose
• snap-telemetry
• stout
• teleconsole
• terraform@0.11
• vert

Corner cases

• docker - upstream uses modules to manage a vendor folder but has no plans to move to a conventional Go modules setup
• gcsfuse - need a closer look; current approach involves deleting and maybe setting a custom GOPATH?
• kops - upstream supports modules but the Makefile seems to download the package from k8s.io at build time?
• operator-sdk - Makefile uses GOBIN to install binaries, but does not use GOPATH
• perkeep - upstream uses modules but their build system puts the binary in GOPATH/bin (i.e. in HOMEBREW_CACHE/go_mod_cache/bin if we don't set GOPATH)
• pulumi - Makefile downloads some prebuilt binaries?
• vault - Makefile downloads its own copy of Homebrew-provided stuff (e.g. gox)

I would like to contribute to this Project

Go for it

can anyone guide me

Hi @rahul3002, I encourage you to take a look at our contributing guide for info on how to contribute in this repository (Homebrew/homebrew-core), which stores formulae (packages) for Homebrew.

You may also be interested in contributing to the main brew repo (https://github.com/Homebrew/brew), which contains the code for the package manager itself. You can also refer to the contributing guidelines for the brew repo for info on how to contribute there.

You can also find more information relevant to contributing at our docs site. I would ask that you to take further questions to our Discussions forum, as this thread is dedicated to other purposes. Thanks for your interest!