cmd/go: Why not separate the module name and the download URL?

[googollee]

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

$ go version
go version go1.11.5 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

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/googol/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/googol/.local:/Users/googol/code"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.5/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/googol/code/test/mod/main/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m1/lzxjk_814flggng3y1299ws80000gn/T/go-build011365699=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I have a package with go module in github.com/googollee/mypkg. The go.mod file is

module mypkg

Then I go get this package and want to use it in another project with go module.

What did you expect to see?

go get runs successfully and I can import with name mypkg.

Separating the module name and the download URL will have benefits below:

• Shorten the import clause.

• Won't mislead the address of importing packages.

• If someone forked projects, no need to change import paths in existing codes.

E.g., I use mypkg in another project Main and import like below:

package main

import "mypkg"

Saying, Bob wants to add some patches and forks both project mypkg and project Main. He could just change the URL in project Main's go.mod to use project mypkg which he forked and keeps all other codes same as upstream. It's not only make the import clause clearly but also reduce the work when catching up the upstream code.

What did you see instead?

When I go get in another project with go.mod, I got:

$ go get github.com/googollee/mypkg
go: finding github.com/googollee/mypkg latest
go: github.com/googollee/mypkg@v0.0.0-20190214221749-17c478c01416: parsing go.mod: unexpected module path "mypkg"
go: error loading module requirements

[UFOXD]

Go do not separate the module name and the download URL that is sick

[mvdan]

@AllenYN reminder to keep it civil in the issue tracker. Only comment if you have technical arguments about the issue. "this is sick" doesn't really add anything meaningful to the thread.

@googollee there's good reason to include the module path in go.mod. For one, that's exactly how a module is uniquely identified; see https://github.com/golang/go/wiki/Modules#gomod.

I presume losing that property would have a high cost, besides being a backwards incompatible change. I'm not convinced that the advantages are worth it.

Shorten the import clause.

This doesn't seem like a strong argument. Verbosity is fine if it adds useful information.

Won't mislead the address of importing packages.

Like I described above, this information is required on purpose. There's no misleading.

If someone forked projects, no need to change import paths in existing codes.

You can just use replace directives; see https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive.

[googollee]

@mvdan, I know there is replace directives. From my recent experience, it's kind of misleading thing. I go to the original repo instead of forked one many times when I just check the code and go directly to the importing address. Further more, I recognize the forked repo is the branch of the original one, but not a different repo. They should share the same identifier in some way.

[mvdan]

They should share the same identifier in some way.

And they do. Both go.mod files must have module github.com/googollee/mypkg lines.

[bcmills]

• Shorten the import clause.

Module-mode has a different goal for the import clause: namely, each package in the build should come from only one location, and that location should be easily derived from the path.

• Won't mislead the address of importing packages.

I'm not sure what you mean by this.

• If someone forked projects, no need to change import paths in existing codes.

If both forks are maintained, then it is important for importers to be explicit about which fork they actually tested against. Today, they do that using a replace directive in the go.mod file.

[bcmills]

Coupling the module path to the URL has another purpose, too: it eliminates the possibility of collisions without the need to maintain our own central module-path registrar.

The Domain Name System already moderates a global namespace, and we need to use DNS to fetch modules anyway, so we may as well piggyback uniqueness of the Go import-path namespace on the existing system of unique URL paths.

This aspect of the modules design is not going to change.

[sound2gd]

so if I want to fix some bugs from original author's repo, I need to both modify go.mod, use replace directive and change module xxxxx, and when I pull a merge request, I need change back, which is not friendly.

[matthias50]

@sound2gd I encountered this use case and worked around it via the method outlined here: #29299 (comment)

[bcmills]

@sound2gd, if you have a repo that is only usable as a replacement for a specific module, then the module directive in the go.mod file can (and should!) list that specific module. It should work fine with a replace directive.