Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: go mod init accepts malformed module paths #36774

Open
perillo opened this issue Jan 26, 2020 · 6 comments
Open

cmd/go: go mod init accepts malformed module paths #36774

perillo opened this issue Jan 26, 2020 · 6 comments

Comments

@perillo
Copy link

@perillo perillo commented Jan 26, 2020

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

$ go version
go version go1.14beta1 linux/amd64

Does this issue reproduce with the latest release?

go1.14beta1 is the latest release

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

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/manlio/.local/bin"
GOCACHE="/home/manlio/.cache/go-build"
GOENV="/home/manlio/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY="github.com/perillo"
GONOSUMDB="github.com/perillo"
GOOS="linux"
GOPATH="/home/manlio/.local/lib/go:/home/manlio/src/go"
GOPRIVATE="github.com/perillo"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/manlio/sdk/go1.14beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/manlio/sdk/go1.14beta1/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/manlio/src/go/src/mperillo/bar/go.mod"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build515447885=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.14beta1 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.14beta1
uname -sr: Linux 5.4.13-arch1-1
/usr/lib/libc.so.6: GNU C Library (GNU libc) stable release version 2.30.
gdb --version: GNU gdb (GDB) 8.3.1

What did you do?

go mod init mperillo/test

What did you expect to see?

go: malformed module path "mperillo/test": missing dot in first path element

What did you see instead?

go: creating new go.mod: module mperillo/test

The problem is that go build will report an error if another module add as requirement mperillo/test.

In this case, is there a reason to allow go mod init to accept such module path?

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Jan 27, 2020

cc @matloob @bcmills

Module paths without a dot in the first path element are allowed, but they cannot be downloaded using that name. That means they cannot appear in a require directive unless there's also a replace directive that provides an alternative location. So module paths like this really only useful for top-level modules not required by anything.

I don't think this documented anywhere. CL 214377 covers this.

@jayconrod jayconrod added this to the Backlog milestone Jan 27, 2020
@perillo
Copy link
Author

@perillo perillo commented Jan 27, 2020

I think this will cause the term module path to be no more consistent.

What is the definition of the term module path?
Some commands say that is a file path, with the first path segment having a dot.
Other commands say that is just a file path.

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 27, 2020

A module path is an import-path suffix of the packages contained within a module.

It may or may not contain a dot. We should update the “malformed module path” error message to be clearer about what, exactly, is wrong. (The problem is not that the module path is malformed per se, but rather that paths of that form cannot be fetched to the module cache.)

@perillo
Copy link
Author

@perillo perillo commented Jan 27, 2020

The problem is that it is not entirely true that a module path without a dot in the first path segment can not be fetched. It depends on the resolver.

Consider an import path like localhost/test. I suspect that the go tool would be able to fetch it, if not for the explicit check for the dot.

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 27, 2020

No, it would not. Dotless import paths are in general reserved for the standard library: if they are not in the standard library, and not supplied via a replace directive, then they will not be fetched even if the hostname can be resolved.

(Otherwise the meaning of an import path could become nondeterministic based on the set of hostnames on the network, which seems way too subtle.)

@perillo
Copy link
Author

@perillo perillo commented Jan 27, 2020

I tried with a module path localhost.localdomain/a.git but go is not able to fetch it:

build localhost.localdomain/b.git: cannot load localhost.localdomain/a.git: git ls-remote -q git://localhost.localdomain/a in /home/manlio/.local/lib/go/pkg/mod/cache/vcs/05929cb418a01ea28941e79c19cd8cf77a461495799d14636e9011e6b0d72a4a: exit status 128:
	fatal: unable to connect to localhost.localdomain:
	localhost.localdomain[0: ::1]: errno=Connection refused
	localhost.localdomain[1: 127.0.0.1]: errno=Connection refused

So I guess the term remote module path, similar to https://golang.org/pkg/cmd/go/#hdr-Remote_import_paths, is more easy to understand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.