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

@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.

@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.

They should share the same identifier in some way.

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

• 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.

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.

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.

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

@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.