cmd/go: go mod tidy does not fail when ambiguous import path found

[jeanbza]

I perform the following steps:

- add /go.mod
- add /pkg_a/foo.go
- add /pkg_b/bar.go
- commit
- tag v0.0.1 # should be unrelated, AFAICT
- push commit + tag

- add /pkg_b/go.mod
- commit
- tag pkg_b/v0.0.1
- push commit + tag

- make pkg_a/foo.go depend on pkg_b/bar.go
- cd pkg_a && go mod tidy
== nothing

- add "require pkg_b v0.0.1" to /pkg_a/go.mod
- cd pkg_a && go mod tidy
== removes require statement in /pkg_a/go.mod

Why does go mod think that pkg_a does not need a require statement for pkg_b?

[odeke-em]

Thank you for reporting this issue and great to catch you here @jadekler!
Let me tag some experts for help, @myitcv @rsc

[myitcv]

@jadekler I don't see anything wrong with the above, indeed a quick repro works just fine (results):

$ cd $(mktemp -d)
$ git init -q
$ git remote add origin https://github.com/go-modules-by-example-staging/20181109100134_jadekler
$ go mod init
go: creating new go.mod: module github.com/go-modules-by-example-staging/20181109100134_jadekler
$ mkdir pkg_a pkg_b
$ cat <<EOD >pkg_a/foo.go
package pkg_a

const Name = "pkg_a"
EOD
$ cat <<EOD >pkg_b/bar.go
package pkg_b

const Name = "pkg_b"
EOD
$ git add -A
$ git commit -q -am 'Initial commit of a and b'
$ git push -q
remote:
remote: Create a pull request for 'master' on GitHub by visiting:
remote:      https://github.com/go-modules-by-example-staging/20181109100134_jadekler/pull/new/master
remote:
$ git tag v0.0.1
$ git push origin v0.0.1
To https://github.com/go-modules-by-example-staging/20181109100134_jadekler
 * [new tag]         v0.0.1 -> v0.0.1

# Make pkg_b a submodule

$ cd pkg_b
$ go mod init github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_b
go: creating new go.mod: module github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_b
$ cd ..
$ git add -A
$ git commit -q -am 'Make b a submodule'
$ git push
To https://github.com/go-modules-by-example-staging/20181109100134_jadekler
   70c6b1f..995050c  master -> master
$ git tag pkg_b/v0.0.1
$ git push origin pkg_b/v0.0.1
To https://github.com/go-modules-by-example-staging/20181109100134_jadekler
 * [new tag]         pkg_b/v0.0.1 -> pkg_b/v0.0.1

# Make pkg_a depend on pkg_b

$ cat <<EOD >pkg_a/foo.go
package pkg_a

import "github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_b"

const Name = "pkg_a"
const OtherName = pkg_b.Name
EOD
$ go mod tidy
go: finding github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_b v0.0.1
go: downloading github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_b v0.0.1
$ cat go.mod
module github.com/go-modules-by-example-staging/20181109100134_jadekler

require github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_b v0.0.1
$ go test github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_a
?       github.com/go-modules-by-example-staging/20181109100134_jadekler/pkg_a  [no test files]

I wonder however, if instead of:

- make pkg_a/foo.go depend on pkg_b/bar.go

you actually meant to add the reverse dependency, i.e.:

- make pkg_b/bar.go depend on pkg_a/foo.go

Because if so, that will have caused a problem. Reason being, when the go tool tries to resolve pkg_a from within the submodule pkg_b, it only finds v0.0.1 or the parent module. And that version contains pkg_b as a package in the main module, and not as a submodule (which happened afterwards). go mod tidy should I think fail in this situation, just as go test does (results):

# ...

# Make pkg_b depend on pkg_a

$ cd pkg_b
$ cat <<EOD >bar.go
package pkg_b

import "github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_a"

const Name = "pkg_b"
const OtherName = pkg_a.Name
EOD
$ go mod tidy
go: finding github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_a latest
go: finding github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse v0.0.1
go: downloading github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse v0.0.1
$ cat go.mod
module github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_b
$ go test github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_b
go: finding github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_a latest
can't load package: package github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_b: unknown import path "github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_b": ambiguous import: found github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_b in multiple modules:
        github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse/pkg_b (/tmp/tmp.ii4Gp8vqRa/pkg_b)
        github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse v0.0.1 (/home/gopher/pkg/mod/github.com/go-modules-by-example-staging/20181109100151_jadekler_reverse@v0.0.1/pkg_b)

The way to fix this is to either tag a new version of the main module at the same commit where the pkg_b submodule is created, or to add a replace statement in pkg_b's go.mod to the parent directory. Here is the replace option (results):

# ...

# Make pkg_b depend on pkg_a

$ cd pkg_b
$ cat <<EOD >bar.go
package pkg_b

import "github.com/go-modules-by-example-staging/20181109100214_jadekler_replace/pkg_a"

const Name = "pkg_b"
const OtherName = pkg_a.Name
EOD

# Use a replace statement

$ go mod edit -replace=github.com/go-modules-by-example-staging/20181109100214_jadekler_replace=../
$ cat go.mod
module github.com/go-modules-by-example-staging/20181109100214_jadekler_replace/pkg_b

replace github.com/go-modules-by-example-staging/20181109100214_jadekler_replace => ../
$ go mod tidy
go: finding github.com/go-modules-by-example-staging/20181109100214_jadekler_replace/pkg_a latest
go: finding github.com/go-modules-by-example-staging/20181109100214_jadekler_replace v0.0.1
$ cat go.mod
module github.com/go-modules-by-example-staging/20181109100214_jadekler_replace/pkg_b

replace github.com/go-modules-by-example-staging/20181109100214_jadekler_replace => ../

require github.com/go-modules-by-example-staging/20181109100214_jadekler_replace v0.0.1
$ go test github.com/go-modules-by-example-staging/20181109100214_jadekler_replace/pkg_b
?       github.com/go-modules-by-example-staging/20181109100214_jadekler_replace/pkg_b  [no test files]

cc @rsc @bcmills for any opinions on whether go mod tidy should be failing in this situation.

[jeanbza]

AH. Sorry, this is my mistake. I'm using intellij, and it seems my auto-import pulled in some other, similarly-named-but-not-correct-path variable. Sorry again, user error.

Although my question is solved (thanks again @myitcv), I'll leave this open for y'all to close at your discretion if you want to discuss the question posed at the end of @myitcv post.

[bcmills]

If I understand correctly, this is a duplicate of #27063.