blob: c20583b22a136822effc89c7844217ab4ea8c8e4 [file] [log] [blame]
# This test illustrates a case where an upgrade–downgrade–upgrade cycle can
# result in upgrades of otherwise-irrelevant dependencies.
#
# This case has no corresponding test in the mvs package, because it is an
# artifact that results from the composition of *multiple* MVS operations.
# The initial package import graph used in the test looks like:
#
# m ---- a
# | |
# +----- b
# | |
# +----- c
# |
# +----- d
#
# b version 2 adds its own import of package d.
#
# The module dependency graph initially looks like:
#
# m ---- a.1
# | |
# +----- b.1
# | |
# +----- c.1
# |
# +----- d.1
#
# b.2 ---- c.2
# |
# +------ d.2
# |
# +------ e.1
#
# If we upgrade module b to version 2, we will upgrade c and d and add a new
# dependency on e. If b version 2 is disallowed because of any of those
# dependencies, the other dependencies should not be upgraded as a side-effect.
cp go.mod go.mod.orig
go mod tidy
cmp go.mod go.mod.orig
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 '
stdout '^example.com/d v0.1.0 '
! stdout '^example.com/e '
# b is imported by a, so the -u flag would normally upgrade it to v0.2.0.
# However, that would conflict with the explicit c@v0.1.0 constraint,
# so b must remain at v0.1.0.
#
# If we're not careful, we might temporarily add b@v0.2.0 and pull in its
# upgrades of module d and addition of module e, which are not relevant to
# b@v0.1.0 and should not be added to the main module's dependencies.
go get -u -d example.com/a@latest example.com/c@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 '
stdout '^example.com/d v0.1.0 '
! stdout '^example.com/e '
-- go.mod --
module example.com/m
go 1.16
require (
example.com/a v0.1.0
example.com/b v0.1.0
example.com/c v0.1.0
example.com/d v0.1.0
)
replace (
example.com/a v0.1.0 => ./a1
example.com/b v0.1.0 => ./b1
example.com/b v0.2.0 => ./b2
example.com/c v0.1.0 => ./c
example.com/c v0.2.0 => ./c
example.com/d v0.1.0 => ./d
example.com/d v0.2.0 => ./d
example.com/e v0.1.0 => ./e
)
-- m.go --
package m
import (
_ "example.com/a"
_ "example.com/b"
_ "example.com/c"
_ "example.com/d"
)
-- a1/go.mod --
module example.com/a
go 1.16
require example.com/b v0.1.0
-- a1/a.go --
package a
import _ "example.com/b"
-- b1/go.mod --
module example.com/b
go 1.16
require example.com/c v0.1.0
-- b1/b.go --
package b
import _ "example.com/c"
-- b2/go.mod --
module example.com/b
go 1.16
require (
example.com/c v0.2.0
example.com/d v0.2.0
example.com/e v0.1.0
)
-- b2/b.go --
package b
import (
"example.com/c"
"example.com/d"
"example.com/e"
)
-- c/go.mod --
module example.com/c
go 1.16
-- c/c.go --
package c
-- d/go.mod --
module example.com/d
go 1.16
-- d/d.go --
package d
-- e/go.mod --
module example.com/e
go 1.16
-- e/e.go --
package e