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

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

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.

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.

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^^

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

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.

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.

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.

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^^

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

@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

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.

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.

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.

@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

At this point all of the information requested in the issue title is described in http://golang.org/wiki/Modules (thanks @thepudds!).

Specifically, see:

• http://golang.org/wiki/Modules#semantic-import-versioning
• https://golang.org/wiki/Modules#modules
• https://golang.org/wiki/Modules#releasing-modules-v2-or-higher