cmd/go: GOPATH mode rejects directory arguments outside of GOPATH/src that contain '@' characters

[metux]

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

go version go1.14 linux/386

Does this issue reproduce with the latest release?

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

go env Output

GO111MODULE=""
GOARCH="386"
GOBIN=""
GOCACHE="/home/nekrad/.cache/go-build"
GOENV="/home/nekrad/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/lib/go-1.13"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.14/pkg/tool/linux_386"
GCCGO="gccgo"
GO386="387"
AR="ar"
CC="gcc"
CXX="g++"
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 -m32 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build963122998=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Building w/ 'go build' and setting GOPATH to a directory that happens to have @ in its name.

What did you expect to see?

Build w/o errors

What did you see instead?

/usr/lib/go-1.14/bin/go build -ldflags "-s -w" -o /home/nekrad/src/deb-pkg/pkg/moby-engine@master.git/tmp/build/dockerd-linux-i386 /home/nekrad/src/deb-pkg/pkg/moby-engine@master.git/cmd/dockerd
can't load package: package /home/nekrad/src/deb-pkg/pkg/moby-engine@master.git/cmd/dockerd: cannot use path@version syntax in GOPATH mode

It tries to do some magic interpretation on an opaque directory name, which it should NOT do.
The directory names are externally given by some infrastructure.
'go build' just should take it as it is (and cope w/ all characters that are allowed for file names on Linux/Unix platforms).

[cagedmantis]

go1.14 is not one of the actively supported versions (go1.15, go1.16). Can you reproduce the issue with one of the supported versions?

[metux]

go1.14 is not one of the actively supported versions (go1.15, go1.16). Can you reproduce the issue with one of the supported versions?

Unfortunately, I have to cope with whats delivered by (stable) distros. Even 1.14 is only delivered by additional backport repos, no 1.15 available.

[mvdan]

Like @cagedmantis said, 1.14.x is no longer supported, so even if a bug was spotted here, at most there would be a backport to 1.15.x.

I imagine that what's happening here is that @ is not allowed in package paths, as it clashes with the modules syntax to specify a version, like go get foo/bar@v1.2.3.

Consider escaping that special character, just like you might usually do for slashes or spaces.

@bcmills where are these restrictions documented? I don't see it in go help importpath or go help packages.

[seankhliao]

I believe the current set of restrictions are #45549 and @ hasn't been allowed since modules were introduced in 1.11

cc @jayconrod @matloob

[bcmills]

Building w/ 'go build' and setting GOPATH to a directory that happens to have @ in its name.

Please provide concrete steps to reproduce the observed behavior using a supported version of the go tool (1.16.3 or 1.15.11).

The posted go env output (GOPATH="/usr/lib/go-1.13") does not appear to correspond to “setting GOPATH”. The specific details are very relevant to the validation that the go command performs, so if we are to address the underlying use-case we need to know how to reproduce it accurately.

[metux]

I believe the current set of restrictions are #45549 and @ hasn't been allowed since modules were introduced in 1.11

cc @jayconrod @matloob

I'm confused - this wasn't supposed to be a module name, but a plain path name in GOPATH.

Meanwhile I've found a workaround (pretty dirty hack) to build moby, but autogenerating go.mod via 'go mod init'.
BUT: I need to point GOPATH to an unwritable directly, so it can't download anything - otherwise lots of errors break the build.
This is very ugly, but at least seems to work (somehow).

Is there any way for preventing any downloads and remote access completely ?

--mtx

[jayconrod]

Based on the command you posted earlier, I expect you'll still see this error (with a slightly different message) in Go 1.16 because of this argument:

/home/nekrad/src/deb-pkg/pkg/moby-engine@master.git/cmd/dockerd

To avoid confusion and ambiguous commands, go build disallows @ characters in arguments except when they're used in path@version arguments in module mode.

This isn't a problem for import paths, since the language spec does not allow @ characters in import declarations. It may be a problem (as in this case) for relative and absolute directory paths, but I think it's better to keep the current strict behavior rather than change anything.

I'm confused - this wasn't supposed to be a module name, but a plain path name in GOPATH.

/home/nekrad/src/deb-pkg/pkg/moby-engine@master.git/cmd/dockerd is a directory path. You may be able to build dockerd using its normal package path instead, but it looks like this has been customized enough that I'm not sure what that would be. cmd/dockerd maybe?

Is there any way for preventing any downloads and remote access completely ?

In module-aware mode, go mod vendor will build a vendor directory (fetching what it needs from the network), then you can build offline with -mod=vendor (which may be enabled automatically, depending on the go version in go.mod). There are a few ways to build offline, but that's probably the easiest.

[bcmills]

To avoid confusion and ambiguous commands, go build disallows @ characters in arguments except when they're used in path@version arguments in module mode.

The go command should (and does!) allow arguments that contain the @ character if they unambiguously refer to a directory rather than a package import path:

$ go version
go version devel go1.17-1108cbe60 Thu May 6 02:21:55 2021 +0000 linux/amd64

$ mkdir foo@bar

$ cd foo@bar

foo@bar$ go mod init example.com/bar
go: creating new go.mod: module example.com/bar

foo@bar$ cat > main.go
package main

func main() {}

foo@bar$ pwd
/tmp/tmp.eEQh4n8Unb/foo@bar

foo@bar$ go build $(pwd)

foo@bar$ ls
bar  go.mod  main.go

foo@bar$

However, in GOPATH mode when outside of GOPATH/src, the go command synthesizes an import path for the working directory based on its file path. It appears that when the directory includes an @ symbol, that synthesized import path also includes an @ symbol and is then rejected as an argument:

foo@bar$ go list .
example.com/bar

foo@bar$ export GO111MODULE=off

foo@bar$ go list .
_/tmp/tmp.eEQh4n8Unb/foo@bar

foo@bar$ go build .

foo@bar$ go build $(pwd)
package /tmp/tmp.eEQh4n8Unb/foo@bar: can only use path@version syntax with 'go get' and 'go install' in module-aware mode