I propose to extend the syntax of go.mod's replace directive to support a remote location target. the remote location that is always the repo hosted in a remote self-hosted git server(or other vcs server) can be a valid target of replace. the below go.mod is an example of my proposal. we know the example is invalid in latest go version.

module github.com/bigwhite/demo
 
go 1.20

require (
    mycompany.com/go/common v1.1.0
)

replace mycompany.com/go/common v1.1.0 => 192.168.10.159/ard/go/common v1.1.0

or replace mycompany.com/go/common  => 192.168.10.159/ard/go/common

or replace mycompany.com/go/common  => 192.168.10.159/ard/go/common v1.1.0

or replace mycompany.com/go/common  v1.1.0 => 192.168.10.159/ard/go/common

Background

Even though Go has evolved to Go 1.20, smaller go development teams still have problems with complex configurations for pulling private modules.

Take our team for example, the private modules that our project depends on are placed on a self-built gitlab server (e.g. 192.168.10.159), which is not accessible via domain name, but only via ip address, and we have defined the canonical import path (mycompany.com/go/xxx) for these private modules.

Our solution now is to pull these private modules through a private self-built GO proxy server (e.g. 192.168.10.10:10000)+govanityurls+nginx, And each developer needs to configure like below:

export GOPROXY='http://192.168.10.10:10000|https://goproxy.io'

Although not particularly complex, maintaining the private GO PROXY service is tedious for small team like us. We want to be able to pull these private modules with cannoical import paths without using a private proxy.

Inspired by rust cargo, we thought about whether our requirement could be achieved based on the current go module mechanism：

- Based on the existing syntax
- Minimal changes
- go.mod can be submitted to the codebase for versioning, and all group members can use it without using go.work

I came up with the idea of doing it based on go mod replace, which of course requires some extensions to replace.

Once the new proposal is implemented, the subsequent pulling of private modules hosted on our self-built gitlab server by our team will allow us to configure none.

And most importantly, there is no need to maintain a private GO proxy service. and It is extremely easy for small team like us to pull private module(with canonical import path ) hosted in a remote self-hosted vcs server.

It is likely that many small development teams will encounter similar problems to ours.

Related issues but not the same

• proposal: cmd/go: allow GOPRIVATE to provide source repository URI #45611
• proposal: cmd/go: extend syntax go.mod to allow overriding fetch protocol #39536