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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
# This file demonstrates the effect of lazy loading on the reproducibility of
# tests (and tests of test dependencies) outside the main module.
#
# It is similar to the cases in mod_all.txt and mod_lazy_test_horizon.txt, but
# focuses on the effect of "go test" on specific packages instead of the "all"
# pattern.
# The package import graph used in this test looks like:
#
# lazy ---- a
# |
# a_test ---- b
# |
# b_test ---- c
#
# And the non-lazy module dependency graph looks like:
#
# lazy ---- a.1 ---- b.1 ---- c.1
cp go.mod go.mod.old
go mod tidy
cmp go.mod go.mod.old
# In Go 1.15 mode, 'go list -m all' includes modules needed by the
# transitive closure of tests of dependencies of tests of dependencies of ….
go list -m all
stdout '^example.com/b v0.1.0 '
stdout '^example.com/c v0.1.0 '
cmp go.mod go.mod.old
# 'go test' (or equivalent) of any such dependency, no matter how remote, does
# not update the go.mod file.
go list -test -deps example.com/a
stdout example.com/b
! stdout example.com/c
[!short] go test -c -o $devnull example.com/a
[!short] cmp go.mod go.mod.old
go list -test -deps example.com/b
stdout example.com/c
[!short] go test -c -o $devnull example.com/b
[!short] cmp go.mod go.mod.old
go mod edit -go=1.17 a/go.mod
go mod edit -go=1.17 b1/go.mod
go mod edit -go=1.17 b2/go.mod
go mod edit -go=1.17 c1/go.mod
go mod edit -go=1.17 c2/go.mod
go mod edit -go=1.17
# After changing to 'go 1.17` uniformly, 'go list -m all' should prune out
# example.com/c, because it is not imported by any package (or test of a package)
# transitively imported by the main module.
#
# example.com/a is imported,
# and example.com/b is needed in order to run 'go test example.com/a',
# but example.com/c is not needed because we don't expect the user to need to run
# 'go test example.com/b'.
# If we skip directly to adding a new import of c, the dependency is too far
# away for a deepening scan to find, which is fine because the package whose
# test imported it wasn't even it "all". It should resolve from the latest
# version of its module.
# However, if we reach c by running successive tests starting from the main
# module, we should end up with exactly the version required by b, with an update
# to the go.mod file as soon as we test a test dependency that is not itself in
# "all".
cp go.mod go.mod.117
go mod tidy
cmp go.mod go.mod.117
go list -m all
stdout '^example.com/b v0.1.0 '
! stdout '^example.com/c '
# 'go test' of a package (transitively) imported by the main module
# should work without changes to the go.mod file.
go list -test -deps example.com/a
stdout example.com/b
! stdout example.com/c
[!short] go test -c -o $devnull example.com/a
# However, 'go test' of a package that is itself a dependency should require an
# update to the go.mod file.
! go list -test -deps example.com/b
# TODO(#36460): The hint here is wrong. We should suggest
# 'go get -t example.com/b@v0.1.0' instead of 'go mod tidy'.
stderr '^go: updates to go\.mod needed; to update it:\n\tgo mod tidy$'
[!short] ! go test -c -o $devnull example.com/b
[!short] stderr '^go: updates to go\.mod needed; to update it:\n\tgo mod tidy$'
go get -t example.com/b@v0.1.0
go list -test -deps example.com/b
stdout example.com/c
[!short] go test -c -o $devnull example.com/b
# The update should bring the version required by b, not the latest version of c.
go list -m example.com/c
stdout '^example.com/c v0.1.0 '
cmp go.mod go.mod.b
# We should reach the same state if we arrive at it via `go test -mod=mod`.
cp go.mod.117 go.mod
[short] go list -mod=mod -test -deps example.com/a
[!short] go test -mod=mod -c -o $devnull example.com/a
[short] go list -mod=mod -test -deps example.com/b
[!short] go test -mod=mod -c -o $devnull example.com/b
cmp go.mod go.mod.b
-- go.mod --
module example.com/lazy
go 1.15
require example.com/a v0.1.0
replace (
example.com/a v0.1.0 => ./a
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
)
-- go.mod.b --
module example.com/lazy
go 1.17
require example.com/a v0.1.0
require example.com/b v0.1.0 // indirect
replace (
example.com/a v0.1.0 => ./a
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
)
-- lazy.go --
package lazy
import (
_ "example.com/a"
)
-- a/go.mod --
module example.com/a
go 1.15
require example.com/b v0.1.0
-- a/a.go --
package a
-- a/a_test.go --
package a
import (
"testing"
_ "example.com/b"
)
func TestUsingB(t *testing.T) {
// …
}
-- b1/go.mod --
module example.com/b
go 1.15
require example.com/c v0.1.0
-- b1/b.go --
package b
-- b1/b_test.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
This file should not be used, so this syntax error should be ignored.
-- b2/b_test.go --
package b
This file should not be used, so this syntax error should be ignored.
-- c1/go.mod --
module example.com/c
go 1.15
-- c1/c.go --
package c
-- c2/go.mod --
module example.com/c
go 1.15
-- c2/c.go --
package c
This file should not be used, so this syntax error should be ignored.
|
