1# Both example.net/ambiguous v0.1.0 and example.net/ambiguous/pkg v0.1.0 exist. 2# 'go mod tidy' would arbitrarily choose the one with the longer path, 3# but 'go mod tidy' also arbitrarily chooses the latest version. 4 5cp go.mod go.mod.orig 6 7 8# From a clean slate, 'go get' currently does the same thing as 'go mod tidy': 9# it resolves the package from the module with the longest matching prefix. 10 11go get example.net/ambiguous/nested/pkg@v0.1.0 12go list -m all 13stdout '^example.net/ambiguous/nested v0.1.0$' 14! stdout '^example.net/ambiguous ' 15 16 17# From an initial state that already depends on the shorter path, 18# the same 'go get' command should (somewhat arbitrarily) keep the 19# existing path, since it is a valid interpretation of the command. 20 21cp go.mod.orig go.mod 22go mod edit -require=example.net/ambiguous@v0.1.0 23 24go get example.net/ambiguous/nested/pkg@v0.1.0 25go list -m all 26stdout '^example.net/ambiguous v0.1.0$' 27! stdout '^example.net/ambiguous/nested ' 28 29 30# The user should be able to make the command unambiguous by explicitly 31# upgrading the conflicting module... 32 33go get example.net/ambiguous@v0.2.0 example.net/ambiguous/nested/pkg@v0.1.0 34go list -m all 35stdout '^example.net/ambiguous/nested v0.1.0$' 36stdout '^example.net/ambiguous v0.2.0$' 37 38 39# ...or by explicitly NOT adding the conflicting module. 40 41cp go.mod.orig go.mod 42go mod edit -require=example.net/ambiguous@v0.1.0 43 44go get example.net/ambiguous/nested/pkg@v0.1.0 example.net/ambiguous/nested@none 45go list -m all 46! stdout '^example.net/ambiguous/nested ' 47stdout '^example.net/ambiguous v0.1.0$' 48 49 50# The user should also be able to fix it by *downgrading* the conflicting module 51# away. 52 53cp go.mod.orig go.mod 54go mod edit -require=example.net/ambiguous@v0.1.0 55 56go get example.net/ambiguous@none example.net/ambiguous/nested/pkg@v0.1.0 57go list -m all 58stdout '^example.net/ambiguous/nested v0.1.0$' 59! stdout '^example.net/ambiguous ' 60 61 62# In contrast, if we do the same thing tacking a wildcard pattern ('/...') on 63# the end of the package path, we get different behaviors depending on the 64# initial state, and no error. (This seems to contradict the “same meaning 65# regardless of the initial state” point above, but maybe that's ok?) 66 67cp go.mod.orig go.mod 68 69go get example.net/ambiguous/nested/pkg/[email protected] 70go list -m all 71stdout '^example.net/ambiguous/nested v0.1.0$' 72! stdout '^example.net/ambiguous ' 73 74 75cp go.mod.orig go.mod 76go mod edit -require=example.net/ambiguous@v0.1.0 77 78go get example.net/ambiguous/nested/pkg/[email protected] 79go list -m all 80! stdout '^example.net/ambiguous/nested ' 81stdout '^example.net/ambiguous v0.1.0$' 82 83 84-- go.mod -- 85module test 86 87go 1.16 88