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: document the relationship between modules, repositories, and branches #27748

Open
mijola opened this Issue Sep 19, 2018 · 16 comments

Comments

Projects
None yet
6 participants
@mijola

mijola commented Sep 19, 2018

Please answer these questions before submitting your issue. Thanks!

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

GO111MODULE=off go get github.com/gopub/wine
cd $GOPATH/src/github.com/gopub/wine
GO111MODULE=on go build

What did you expect to see?

github.com/gopub/wine shouldn't be included in go.mod

What did you see instead?

github.com/gopub/wine is included in go.mod and the version is v1.0.5 (The highest version of wine is v2.0.1 though)

module github.com/gopub/wine/v2

require (
	github.com/gopub/log v1.0.3
	github.com/gopub/types v1.0.7
	github.com/gopub/utils v1.0.1
	github.com/gopub/wine v1.0.5
)

System details

go version go1.11 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/natan/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/natan/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/natan/go/src/github.com/gopub/wine/go.mod"
GOROOT/bin/go version: go version go1.11 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -v: Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D47
lldb --version: lldb-900.0.64
  Swift-4.0
@mvdan

This comment has been minimized.

Member

mvdan commented Sep 19, 2018

Why shouldn't it be included? I don't understand this issue.

@mijola

This comment has been minimized.

mijola commented Sep 19, 2018

Why shouldn't it be included? I don't understand this issue.

It seems a little wired that module (github.com/gopub/wine) include itself in go.mod if it is imported by another package in the same module (github.com/gopub/wine/examples/... or github.com/gopub/wine/server_test.go).

Even though it's by design. The dependency version is incorrect.
E.g. go build automatically add dependency github.com/gopub/wine v1.0.5, however the highest version is v2.0.1.

And once this module updates, need to bump the version in its own go.mod

Thanks

@mijola mijola changed the title from go1.11 module: unnecessary to include module itself in go.mod to go1.11 module: unnecessary for a module to depend itself in its go.mod Sep 19, 2018

@mvdan

This comment has been minimized.

Member

mvdan commented Sep 19, 2018

Ah, I understand what you mean now.

This is because the module is now github.com/gopub/wine/v2, so all the imports must use imports like github.com/gopub/wine/v2/render and not github.com/gopub/wine/render. If you do the latter, then the go command will pull the latest v1 version, and add it as a dependency.

The v1 and v2 modules can be depended on simultaneously, and they will result in separate modules and packages.

/cc @bcmills @myitcv in case the docs aren't clear enough on this.

@mvdan

This comment has been minimized.

Member

mvdan commented Sep 19, 2018

The closes thing in the Modules FAQ is https://github.com/golang/go/wiki/Modules#semantic-import-versioning. Perhaps it would be good to add a "my v2 module depends on the v1 version of itself" section, if this confusion is common.

@mijola

This comment has been minimized.

mijola commented Sep 19, 2018

Ah, I understand what you mean now.

This is because the module is now github.com/gopub/wine/v2, so all the imports must use imports like github.com/gopub/wine/v2/render and not github.com/gopub/wine/render. If you do the latter, then the go command will pull the latest v1 version, and add it as a dependency.

The v1 and v2 modules can be depended on simultaneously, and they will result in separate modules and packages.

/cc @bcmills @myitcv in case the docs aren't clear enough on this.

I see. Thanks for your explanation^^

@mijola

This comment has been minimized.

mijola commented Sep 19, 2018

Is it possible to remove the dependency on itself? I think it makes sense for another module to explicitly include v2 in the import path. For sub packages inside the module itself, it looks strange to do it. Thanks

@bcmills

This comment has been minimized.

Member

bcmills commented Sep 19, 2018

Is it possible to remove the dependency on itself?

No. An import path must have the same meaning throughout the program: as strange as it looks to use /v2 for imports within the module, it would be even stranger for github.com/gopub/wine to sometimes mean github.com/gopub/wine and sometimes mean github.com/gopub/wine/v2 instead.

@mijola

This comment has been minimized.

mijola commented Sep 19, 2018

Is it possible to remove the dependency on itself?

No. An import path must have the same meaning throughout the program: as strange as it looks to use /v2 for imports within the module, it would be even stranger for github.com/gopub/wine to sometimes mean github.com/gopub/wine and sometimes mean github.com/gopub/wine/v2 instead.

Got it. It seems no perfect solution. Thanks for your explanation.

@mijola mijola closed this Sep 19, 2018

@beoran

This comment has been minimized.

beoran commented Sep 20, 2018

Please don't close this yet. I also lost a day before I could figure out the need to require the module that I am in the go.mod of the module itself, found it highly confusing at. This point should certainly be documented better everywhere.

@mijola

This comment has been minimized.

mijola commented Sep 20, 2018

Please don't close this yet. I also lost a day before I could figure out the need to require the module that I am in the go.mod of the module itself, found it highly confusing at. This point should certainly be documented better everywhere.

OK. I reopen it^^

@mijola mijola reopened this Sep 20, 2018

@beoran

This comment has been minimized.

beoran commented Sep 20, 2018

I propose that we add the documentation tag to this issue and change the topic to "Document the need for modules to require themselves in certain cases".

@mijola mijola changed the title from go1.11 module: unnecessary for a module to depend itself in its go.mod to go1.11 modules: Document the need for modules to require themselves in certain cases Sep 20, 2018

@mijola

This comment has been minimized.

mijola commented Sep 20, 2018

@beoran Did you figure out how to depend itself? I changed all the import path from github.com/gopub/wine to github.com/gopub/wine/v2 within the module. go build still add dependency github.com/gopub/wine v1.0.5 in go.mod

@beoran

This comment has been minimized.

beoran commented Sep 20, 2018

I did find a way that works for me but it's with liberal use of replace, so I feel like might be a hack. I am also using v0.0.0 for the moment so the v2 problem hasn't happened for me yet.

@bcmills

This comment has been minimized.

Member

bcmills commented Sep 26, 2018

Modules do not “require themselves”. github.com/gopub/wine and github.com/gopub/wine/v2 are separate modules, not just different versions of the same module.

@bcmills bcmills changed the title from go1.11 modules: Document the need for modules to require themselves in certain cases to cmd/go: document the relationship between modules, repositories, and branches Sep 26, 2018

@beoran

This comment has been minimized.

beoran commented Sep 26, 2018

Yes, but in ym case I had to add a require of the module itself plus a replace into the go.mod file to get the module to compile. I do work in an all-offline setting. I guess I am doing something wrong, but I don't know what, or how to do it correctly. By all means, please document this more. I guess the most bewildering part is that go modules are unlike anything I used in any other programming language before, not even like units in Pascal.

@thepudds

This comment has been minimized.

thepudds commented Sep 27, 2018

@natande wrote:

I changed all the import path from github.com/gopub/wine to github.com/gopub/wine/v2 within the module. go build still add dependency github.com/gopub/wine v1.0.5 in go.mod

The discussion in this issue has been a bit nuanced, so sorry if my comment is off base.

There are cases where it is indeed very desirable for module foo/v2 to depend on foo (that is, the v1 of foo), but I wonder if there might be something more basic going on in your case?

One question would be have you run go mod tidy after you changed your code's internal import statements from using github.com/gopub/wine/v2 import path to github.com/gopub/wine/v2 import path? In general, go build and go test know how to add requirements, but go mod tidy is needed to prune requirements that were once needed but are no longer needed. See a bit more explanation here:
https://github.com/golang/go/wiki/Modules#how-to-prepare-for-a-release

After running go mod tidy, it would then be interesting for you to check the results of running go mod why -m <module> for you to see what is causing github.com/gopub/wine to still show up in your module requirements, and perhaps to run go mod graph to get additional insight if go mod why -m <module> gives you a result you don't expect. There is some chance it could be something as simple as a missed import path that still needs to be updated to github.com/gopub/wine/v2, or maybe a test file that needs to be updated, or ___. See a bit more here:
https://github.com/golang/go/wiki/Modules#why-does-go-mod-tidy-record-indirect-and-test-dependencies-in-my-gomod

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment