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