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: Why not separate the module name and the download URL? #30242

Closed
googollee opened this issue Feb 14, 2019 · 7 comments

Comments

Projects
None yet
5 participants
@googollee
Copy link

commented Feb 14, 2019

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

This comment has been minimized.

Copy link

commented Feb 15, 2019

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

@mvdan

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

@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

This comment has been minimized.

Copy link
Author

commented Feb 15, 2019

@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

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

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 bcmills added the modules label Feb 15, 2019

@bcmills bcmills changed the title Why not separate the module name and the download URL? cmd/go: Why not separate the module name and the download URL? Feb 15, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

  • 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

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

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.

@bcmills bcmills closed this Feb 15, 2019

@sound2gd

This comment has been minimized.

Copy link

commented Apr 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.