cmd/go: mod init and mod edit unable to import module paths missing a dot

[roblillack]

Overview and related issues

This issue seems to be related to #26510. But in this case, not the actual module I am working with is "dotless," but a dependency.

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

go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rob/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/rob/dev/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.4/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/19/2k3s854n17d44rsgblw41www0000gn/T/go-build831329113=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Trying to initialize Go Modules with go mod init in a go package that has a “dotless” package dependency (package name “projectx”) which is to be downloaded from a location that cannot be deducted from the package name (might be an internal git server, etc.) configured using glide.yaml:

package: github.com./roblillack/my-internal-go-tool

import:
  - package: projectx
    repo: [email protected]:roblillack/my-internal-go-library.git

(You can clone a the repo with this testcase from https://github.com./roblillack/my-internal-go-tool)

What did you expect to see?

I expected a go.mod being created like this:

module github.com./roblillack/my-internal-go-tool

require projectx v0.0.0-20190108172907-e2cf823506ac

replace projectx => github.com./roblillack/my-internal-go-library v0.0.0-20190108172907-e2cf823506ac

And this should have been the output of go run .:

$ go run .
go: downloading github.com./roblillack/my-internal-go-library v0.0.0-20190108172907-e2cf823506ac
Hello from Project X.
$ 

What did you see instead?

$ go mod init
go: creating new go.mod: module github.com./roblillack/my-internal-go-tool
go: copying requirements from glide.lock
go: converting glide.lock: stat projectx@e2cf823506ac75c09972462f36e747f437d1585a: unrecognized import path "projectx" (import path does not begin with hostname)
$ 

… and go.mod looks like this:

module github.com/roblillack/my-internal-go-tool

// go: no requirements found in glide.lock

This way, of course go run . does not work:

go run .
build github.com./roblillack/my-internal-go-tool: cannot find module for path projectx

Likewise, adding the dependency using go mod edit does not work, too:

$ go mod edit -require projectx@latest -replace projectx=github.com./roblillack/my-internal-go-library
go mod: -require=projectx@latest: invalid path: malformed module path "projectx": missing dot in first path element
$ 

When creating/editing the require & replace actions in go.mod manually, go run . will work as expected.

[agnivade]

/cc @bcmills

[mvdan]

Previous related issue: #26894

What I personally do is set up a ~/.netrc file, and then I can just use HTTPS for private repos - this includes the ones at work where we use Go modules. Not saying it's the best way, but it's certainly an alternative that works now.

[bcmills]

The fact that we do not convert replacement paths from glide.yaml is #25556.

Dotless paths are in general reserved for the Go standard library. They do not work with go get in GOPATH mode, and they do not work with go get in module mode. (It's unlikely that we'll use projectx in particular, but I don't see a compelling reason to relax the general rule.)

For internal Git servers, my recommendation is to give the server a proper, resolvable two-level DNS name rather than relying on replace directives.

[roblillack]

Thanks @bcmills. Regarding

Dotless paths are in general reserved for the Go standard library.

and

I don't see a compelling reason to relax the general rule.

can you please point me to a place where this (new to me) rule is defined? I cannot find it in any of these locations:

• go help importpath
• https://blog.golang.org/package-names
• https://golang.org/doc/effective_go.html#names
• https://golang.org/doc/faq

I do understand that using what the documentation calls “remote import paths” is an encouraged convention. If, for whatever reason, having non-resolvable or dotless names as import path prefixes is discouraged from now on, I'd love to see it officially documented somewhere.

For the record, an actual related issue seems to be #27503.