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/...@v0.1.0
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/...@v0.1.0
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
View as plain text