/cc @rsc @bcmills

It looks like you're trying to point GOPROXY at a source tree. That's not how it works. GOPROXY is expected to point at a tree of .zip files and .mod files, not source files. I believe you should be able to point GOPROXY at your module cache, which is $GOPATH/pkg/mod/cache/download, though I haven't tried this myself.

This is all more or less explained in the documentation that you linked: https://golang.org/cmd/go/#hdr-Module_proxy_protocol.

Yes I missed that part:

Even when downloading directly from version control systems, the go command synthesizes explicit info, mod, and zip files and stores them in its local cache, $GOPATH/pkg/mod/cache/download, the same as if it had downloaded them directly from a proxy. The cache layout is the same as the proxy URL space, so serving $GOPATH/pkg/mod/cache/download at (or copying it to) https://example.com/proxy would let other users access those cached module versions with GOPROXY=https://example.com/proxy.

I am specifically trying to use go modules in an environment where there is no direct internet connection. I was hoping that it would be simple, but no such luck.

So I've done more testing. I set GOPATH to e.g. C:\gopath, cached the modules, and tried:

set GOPROXY=file:///C:/gopath/pkg/mod/cache/download
go run .

and that didn't work!

But, after accidentally making a typo, I discovered that THIS works:

set GOPROXY=file://C:/gopath/pkg/mod/cache/download
go run .

Note the two leading slashes instead of three.

Now per my recollection, and Wikipedia supports me here, I'd expect the former to work and the later not to work. So there still seems to be a bug in here somewhere.

I am specifically trying to use go modules in an environment where there is no direct internet connection.

FWIW, go mod download is the intended command for that use-case: you should be able to run go mod download on a machine with a network connection, then copy GOPATH/pkg/mod/cache/download to your disconnected builder.

https://blogs.msdn.microsoft.com/ie/2006/12/06/file-uris-in-windows/ does seem to support the triple-slash as canonical.

Probably we need to do something more robust to translate the URI path to a file path here:

(CC @alexbrainman, in case he has any advice on Go idioms to convert Windows URL paths to file paths.)

https://play.golang.org/p/5uOiwDwU0n4 for reference on the behavior of http.NewRequest.

https://blogs.msdn.microsoft.com/ie/2006/12/06/file-uris-in-windows/ does seem to support the triple-slash as canonical.

LGTM.

You could also look in net/url package - we already have some tests for urls that starts with file:///C:/.... Just remember that these paths are case insensitive on Windows (just like normal file paths on Windows).

Alex

OK, so the URL parser is putting the leading slash in, and on Windows we should take it out if the result passes filepath.IsAbs.

Change https://golang.org/cl/181037 mentions this issue: cmd/go/internal/web: support file:// URLs