cmd/go: "go get" should create a replcae line automatically if the get path and moudle path don't match

[zigo101]

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

go version go1.12 linux/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

$ go get github.com/go101/tinyrouter@v1.0.1

The module path set in go.mod is go101.org/tinyrouter, not github.com/go101/tinyrouter.

What did you expect to see?

no errors, and automatically create a replace line in go.mod file of the app project after parsing the go-got go.mod file:

replace go101.org/tinyrouter => github.com/go101/tinyrouter v1.0.1

What did you see instead?

go: github.com/go101/tinyrouter@v1.0.1: parsing go.mod: unexpected module path "go101.org/tinyrouter"
go: error loading module requirements

[dmitshur]

What's the motivation for it to automatically create a replace line in go.mod file?

At first glance, that kind of behavior would be unexpected and surprising to me, given how go get is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get. It would be helpful to better understand the motivation behind this.

[zigo101]

I think the motivation is straightforward. The intention of why I run "go get" is just to add a dependency to the current module-aware user package. For the library package is hosted on github.com, certainly I can't run "go get go101.org/tinyrouter@v1.0.1", for the library package isn't hosted on go101.org. The go101.org can even be a non-existing website.

[zigo101]

And I found that, even if I put the replace line manually to the go.mod file, then go get still reports errors when I run either go get go101.org/tinyrouter@v1.0.1 or go get github.com/go101/tinyrouter@v1.0.1.

$ go get go101.org/tinyrouter@v1.0.1
go get go101.org/tinyrouter@v1.0.1: unrecognized import path "go101.org/tinyrouter" (parse https://go101.org/tinyrouter?go-get=1: no go-import meta tags ())

$ go get github.com/go101/tinyrouter@v1.0.1
go: github.com/go101/tinyrouter@v1.0.1: parsing go.mod: unexpected module path "go101.org/tinyrouter"
go: error loading module requirements

I really don't know why go get still would connect to go101.org even if I have set a replace line in go.mod. What is the intention of replace lines?

[zigo101]

go build has no problems.

[dmitshur]

What is the intended import path for Go packages in tinyrouter?

If you want the import path to be github.com/go101/tinyrouter, then you should modify your go.mod file to specify the module path as github.com/go101/tinyrouter, not go101.org/tinyrouter. Then you can go get github.com/go101/tinyrouter@v1.0.1 (or, a newer version).

If you want the import path to be go101.org/tinyrouter, then the https://go101.org/tinyrouter?go-get=1 page should serve a go-import meta tag, as described at https://golang.org/cmd/go/#hdr-Remote_import_paths. Right now, it's serving 404. After that, you will be able to go get go101.org/tinyrouter@v1.0.1 (or later version).

[zigo101]

The intention is to avoid my library users being locked down to github.com.
I would like they use go101.org/tinyrouter as import paths in their source code.
When later, I move the package to another place, such as gitlab.com,
users can just modify the line in go.mod, no needs to modify all the import paths in source code.

Here, the go101.org could be anything other than github.com, for example, website.noexist/tinyrouter. I never prepare to create a http service to response the https://go101.org/tinyrouter?go-get=1 request. Is this not ok?

[zigo101]

If go build thinks it is ok, why not go get?

[jayconrod]

Module paths are canonical: if a module sets the path go101.org/tinyrouter in its go.mod, users must import it by that name in module mode (and as @dmitshur said, there must be an HTTPS server there pointing to wherever the repository is located). This constraint makes a lot of things simpler. Packages can only be imported by one name, and there's much less risk the same package being built multiple times.

replace directives don't seem like the right solution for this. There are a few limited use cases for them (e.g., a short-term fork of an upstream module), but it's better to avoid them if at all possible. Keep in mind that replace directives are only effective for builds in the main module, so adding them is very likely to break downstream users.

Please see When should I use the replace directive? on the module wiki for more information on replace.

See Remove import paths for more information on custom imports. These are popularly (but not officially) called "vanity imports", and there are some articles on setting that up. You definitely need to serve https://go101.org/tinyrouter?go-get=1 though.