Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/go: add unified notation for expressing proxy configurations #31767

Open
mcandre opened this issue Apr 30, 2019 · 1 comment

Comments

Projects
None yet
4 participants
@mcandre
Copy link

commented Apr 30, 2019

Go dependency resolution, unlike other popular systems like NPM, RubyGems, Gradle, and Maven, does not have a unified way to express proxy configurations and ensure that these configurations propagate down to the constituent dependency resolution clients. This makes it difficult to manage large Go dependency trees in restricted environments where access to VCS repositories is tightly controlled through proxy servers.

Mayhap this situation is improved through the recent Go modules system, though I suspect go get is still a pain point for managing developer tools, that are not currently included in the Go modules dependencies specification. In any case, it would be helpful to provide for simplified proxy configuration for Go projects, independent of whether Go modules, or vendored dependencies, or unvendored dependencies, are involved.

The current situation is a mess, with many incomplete and erroneous Google results on how to configure go get / go install. Some posts say to declare a http_proxy environment variable. Other posts mention that git, subversion, and/or mercurial must separately be configured with the proxy details. In practice, it is really easy to get the configurations wrong. I therefore propose that the go tool receive a standard set of proxy parameters, such as through clearly defined environment variable names, and automatically propagate these through to any downstream go get / go install subcommands and their constituent clients, be they HTTP, HTTPS, git, Subversion, Mercurial, etc. etc.

A simple http_proxy environment variable could suffice for many of these configurations. If we like, we can also support HTTP_PROXY, as some applications prefer the uppercase name. https_proxy / HTTPS_PROXY are helpful for specifying different proxies based on the URL scheme. And if we really want to get fancy, SOCKS_SERVER could allow for more advanced proxy configurations.

Perhaps environment variables are too cumbersome, maybe we need standard CLI flags across the different go subcommands to express proxies. But I think we deserve something, so that Go users don't have to setup proxy configuration at multiple abstraction levels, and have to guess which one of these is the root cause of their woes!

@bradfitz

This comment has been minimized.

Copy link
Member

commented Apr 30, 2019

Go dependency resolution, unlike other popular systems like NPM, RubyGems, Gradle, and Maven, does not have a unified way to express proxy configurations

What is the unified way that NPM, RubyGems, Gradle, and Maven do?

@bradfitz bradfitz changed the title Enhancement: Unified notation for expressing proxy configurations proposal: cmd/go: add unified notation for expressing proxy configurations Apr 30, 2019

@gopherbot gopherbot added this to the Proposal milestone Apr 30, 2019

@gopherbot gopherbot added the Proposal label Apr 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.