blob: ced1dcd6b14e37a528f1a9e494c3e93a6acbf804 (
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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
# This test illustrates a case where downgrading one module may upgrade another.
# Compare to the downcross1 test case in cmd/go/internal/mvs/mvs_test.go.
# The package import graph used in this test looks like:
#
# a ---- b
# \ \
# \ \
# ----- c ---- d
#
# The module dependency graph originally looks like:
#
# a ---- b.2
# \ \
# \ \
# ----- c.1 ---- d.2
#
# b.1 ---- c.2
#
# If we downgrade module d to version 1, we must downgrade b as well.
# If that downgrade selects b version 1, we will upgrade module c to version 2.
# So 'go get d@1' should instead downgrade both b and c to "none".
cp go.mod go.mod.orig
go mod tidy
cmp go.mod.orig go.mod
go get -d example.com/d@v0.1.0
go list -m all
! stdout '^example.com/b '
! stdout '^example.com/c '
stdout '^example.com/d v0.1.0 '
-- go.mod --
module example.com/a
go 1.15
require (
example.com/b v0.2.0
example.com/c v0.1.0
)
replace (
example.com/b v0.1.0 => ./b1
example.com/b v0.2.0 => ./b2
example.com/c v0.1.0 => ./c1
example.com/c v0.2.0 => ./c2
example.com/d v0.1.0 => ./d
example.com/d v0.2.0 => ./d
)
-- a.go --
package a
import (
_ "example.com/b"
_ "example.com/c"
)
-- b1/go.mod --
module example.com/b
go 1.15
require example.com/c v0.2.0
-- b1/b.go --
package b
import _ "example.com/c"
-- b2/go.mod --
module example.com/b
go 1.15
require example.com/c v0.1.0
-- b2/b.go --
package b
import _ "example.com/c"
-- c1/go.mod --
module example.com/c
go 1.15
require example.com/d v0.2.0
-- c1/c.go --
package c
-- c2/go.mod --
module example.com/c
go 1.15
-- c2/c.go --
package c
-- d/go.mod --
module example.com/d
go 1.15
|
