Current File : //usr/local/go/src/cmd/go/testdata/script/mod_lazy_downgrade.txt
# This test illustrates the interaction between lazy loading and downgrading in
# 'go get'.
# The package import graph used in this test looks like:
#
# lazy ---- a
# |
# a_test ---- b
# b_test ---- c
#
# The module dependency graph initially looks like:
#
# lazy ---- a.1 ---- b.1 ---- c.1
# \ /
# b.3 ---- c.2 b.2
#
# (Note that lazy loading will prune out the dependency from b.1 on c.1.)
cp go.mod go.mod.orig
go mod tidy
cmp go.mod.orig go.mod
go list -m all
stdout '^example.com/a v0.1.0 '
stdout '^example.com/b v0.3.0 '
stdout '^example.com/c v0.2.0 '
# Downgrading c should also downgrade the b that requires it.
go get -d example.com/c@v0.1.0
go list -m all
stdout '^example.com/a v0.1.0 '
stdout '^example.com/b v0.2.0 '
stdout '^example.com/c v0.1.0 '
# Removing c entirely should also remove the a and b that require it.
go get -d example.com/c@none
go list -m all
! stdout '^example.com/a '
! stdout '^example.com/b '
! stdout '^example.com/c '
# With lazy loading, downgrading c should work the same way, but dependencies
# outside of the deepening scan should not affect the downgrade.
cp go.mod.orig go.mod
go mod edit -go=1.17
go list -m all
stdout '^example.com/a v0.1.0 '
stdout '^example.com/b v0.3.0 '
stdout '^example.com/c v0.2.0 '
go get -d example.com/c@v0.1.0
go list -m all
stdout '^example.com/a v0.1.0 '
stdout '^example.com/b v0.2.0 '
stdout '^example.com/c v0.1.0 '
# At this point, b.2 is still an explicit root, so its dependency on c
# is still tracked, and it will still be downgraded away if we remove c.
# ('go get' never makes a root into a non-root. Only 'go mod tidy' does that.)
go get -d example.com/c@none
go list -m all
! stdout '^example.com/a '
! stdout '^example.com/b '
! stdout '^example.com/c '
# This time, we drop the explicit 'b' root by downgrading it to v0.1.0
# (the version required by a.1) and running 'go mod tidy'.
# It is still selected at v0.1.0 (as a dependency of a),
# but its dependency on c is now pruned from the module graph, so it doesn't
# result in any downgrades to b or a if we run 'go get c@none'.
cp go.mod.orig go.mod
go mod edit -go=1.17
go list -m all
stdout '^example.com/a v0.1.0 '
stdout '^example.com/b v0.3.0 '
stdout '^example.com/c v0.2.0 '
go get -d example.com/c@v0.1.0 example.com/b@v0.1.0
go list -m all
stdout '^example.com/a v0.1.0 '
stdout '^example.com/b v0.1.0 '
stdout '^example.com/c v0.1.0 '
go mod tidy
go list -m all
stdout '^example.com/a v0.1.0 '
stdout '^example.com/b v0.1.0 '
! stdout '^example.com/c '
go get -d example.com/c@none
go list -m all
stdout '^example.com/a v0.1.0'
stdout '^example.com/b v0.1.0'
! stdout '^example.com/c '
-- go.mod --
module example.com/lazy
go 1.15
require (
example.com/a v0.1.0
example.com/b v0.3.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/b v0.3.0 => ./b3
example.com/c v0.1.0 => ./c
example.com/c v0.2.0 => ./c
)
-- lazy.go --
package lazy
import _ "example.com/a"
-- a/go.mod --
module example.com/a
go 1.17
require example.com/b v0.1.0
-- a/a.go --
package a
-- a/a_test.go --
package a_test
import _ "example.com/b"
-- b1/go.mod --
module example.com/b
go 1.17
require example.com/c v0.1.0
-- b1/b.go --
package b
-- b1/b_test.go --
package b_test
import _ "example.com/c"
-- b2/go.mod --
module example.com/b
go 1.17
require example.com/c v0.1.0
-- b2/b.go --
package b
-- b2/b_test.go --
package b_test
import _ "example.com/c"
-- b3/go.mod --
module example.com/b
go 1.17
require example.com/c v0.2.0
-- b3/b.go --
package b
-- b3/b_test.go --
package b_test
import _ "example.com/c"
-- c/go.mod --
module example.com/c
go 1.17
-- c/c.go --
package c
Mini Shell