cmd/go: 'go build' sets arbitrary requirement of module name containing dots · Issue #27503 · golang/go (original) (raw)

All of my dependent modules are in order, and none of them have a hostname prefix that contain dots. The convention we have been using for years with GOPATH is "company/foo/bar", rather than "our.company.com/foo/bar".

What version of Go are you using (go version)?

$ go version
go version go1.11 linux/amd64

What did you do?

Built a proxy which can be used to serve up modules which reflect our real world, which is a world with custom import paths with no "hostname" prefix. Trying to use go build with this proxy and our modules results in the go build command complaining that our modules do not start with a "hostname" prefix, because the first path element in our modules do not contain any dot characters.

First, a view of the modules being served by our proxy

[k9 modprox-modules] $ tree
.
└── indeed
    └── gophers
        ├── 3rdparty
        │   └── p
        │       └── github.com
        │           ├── pkg
        │           │   └── errors
        │           │       ├── v0.0.1.info
        │           │       ├── v0.0.1.mod
        │           │       └── v0.0.1.zip
        │           └── stretchr
        │               └── testify
        │                   ├── assert
        │                   │   ├── v0.0.1.info
        │                   │   ├── v0.0.1.mod
        │                   │   └── v0.0.1.zip
        │                   ├── require
        │                   │   ├── v0.0.1.info
        │                   │   ├── v0.0.1.mod
        │                   │   └── v0.0.1.zip
        │                   └── suite
        │                       ├── v0.0.1.info
        │                       ├── v0.0.1.mod
        │                       └── v0.0.1.zip
        ├── libconfig
        │   ├── v0.0.1.info
        │   ├── v0.0.1.mod
        │   └── v0.0.1.zip
        └── libtest
            ├── v0.0.1.info
            ├── v0.0.1.mod
            └── v0.0.1.zip

14 directories, 18 files

This seems like a reasonable module structure.

A peek at the go.mod file we are about to use:

$ cat go.mod
module indeed/gophers/libconfig

require (
    indeed/gophers/3rdparty/p/github.com/pkg/errors v0.0.1
    indeed/gophers/3rdparty/p/github.com/stretchr/testify/assert v0.0.1 // indirect
    indeed/gophers/3rdparty/p/github.com/stretchr/testify/require v0.0.1
    indeed/gophers/3rdparty/p/github.com/stretchr/testify/suite v0.0.1 // indirect
    indeed/gophers/libtest v0.0.1
)

Lines up fine with the modules being served from the proxy.

Okay let's build it

 $ echo $GOPROXY
http://localhost:12505

$ go build
go: indeed/gophers/3rdparty/p/github.com/stretchr/testify/require@v0.0.1: unrecognized import path "indeed/gophers/3rdparty/p/github.com/stretchr/testify/require" (import path does not begin with hostname)
go: indeed/gophers/libtest@v0.0.1: unrecognized import path "indeed/gophers/libtest" (import path does not begin with hostname)
go: indeed/gophers/3rdparty/p/github.com/pkg/errors@v0.0.1: unrecognized import path "indeed/gophers/3rdparty/p/github.com/pkg/errors" (import path does not begin with hostname)
go: indeed/gophers/3rdparty/p/github.com/stretchr/testify/suite@v0.0.1: unrecognized import path "indeed/gophers/3rdparty/p/github.com/stretchr/testify/suite" (import path does not begin with hostname)
go: indeed/gophers/3rdparty/p/github.com/stretchr/testify/assert@v0.0.1: unrecognized import path "indeed/gophers/3rdparty/p/github.com/stretchr/testify/assert" (import path does not begin with hostname)
go: error loading module requirements

Hmm, that's not useful. The go build command is enforcing import paths to begin with a path element that contains dot characters. This seems totally arbitrary (at least in the context of GOPROXY) and breaks at least this one real world use case (a fix on our end would be "atomically" updating hundreds of repositories and interrupting dozens of developer workflows).

It seems to me at least with GOPROXY set, go build should just trust that the module will be resolvable.