[Go to site: main page, start]

0% found this document useful (0 votes)
9 views3 pages

Go Mod Tidy Compatibility Issues

'go mod tidy' for a Go 1.17 module should maintain checksums for compatibility with Go 1.16. The document discusses how Go 1.17 prunes certain dependencies that Go 1.16 does not, leading to potential errors when switching between versions. It provides commands for module authors to resolve discrepancies and align dependencies across Go versions.

Uploaded by

1mhd.zain1
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views3 pages

Go Mod Tidy Compatibility Issues

'go mod tidy' for a Go 1.17 module should maintain checksums for compatibility with Go 1.16. The document discusses how Go 1.17 prunes certain dependencies that Go 1.16 does not, leading to potential errors when switching between versions. It provides commands for module authors to resolve discrepancies and align dependencies across Go versions.

Uploaded by

1mhd.zain1
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

# [Link] 'go mod tidy' for a Go 1.

17 module should by
# default preserve enough checksums for the module to be used by Go 1.16.
#
# We don't have a copy of Go 1.16 handy, but we can simulate it by editing the
# 'go' version in the [Link] file to 1.16, without actually updating the
# requirements to match.

[short] skip

env MODFMT='{{with .Module}}{{.Path}} {{.Version}}{{end}}'

# For this module, Go 1.17 prunes out a (transitive and otherwise-irrelevant)


# requirement on a retracted higher version of a dependency.
# However, when Go 1.16 reads the same requirements from the [Link] file,
# it does not prune out that requirement, and selects the retracted version.
#
# The Go 1.16 module graph looks like:
#
# m ---- lazy v0.1.0 ---- requireincompatible v0.1.0 ---- incompatible
v2.0.0+incompatible
# | |
# + -------+------------- incompatible v1.0.0
#
# The Go 1.17 module graph is the same except that the dependencies of
# requireincompatible are pruned out (because the module that requires
# it — lazy v0.1.0 — specifies 'go 1.17', and it is not otherwise relevant to
# the main module).

# 'go mod tidy' should by default diagnose the difference in dependencies as an


# error, with useful suggestions about how to resolve it.

cp [Link] [Link]
! go mod tidy
stderr '^example\.com/m imports\n\texample\.net/lazy
imports\n\texample\.com/retract/incompatible loaded from
example\.com/retract/incompatible@v1\.0\.0,\n\tbut go 1\.16 would select
v2\.0\.0\+incompatible\n\n'
stderr '\n\nTo upgrade to the versions selected by go 1\.16:\n\tgo mod tidy -
go=1\.16 && go mod tidy -go=1\.17\nIf reproducibility with go 1\.16 is not needed:\
n\tgo mod tidy -compat=1.17\nFor other options,
see:\n\t[Link]

cmp [Link] [Link]

# The suggested '-compat' flag to ignore differences should silence the error
# and leave [Link] unchanged, resulting in checksum errors when Go 1.16 tries
# to load a module pruned out by Go 1.17.

go mod tidy -compat=1.17


! stderr .
cmp [Link] [Link]

go mod edit -go=1.16


! go list -f $MODFMT -deps ./...
# TODO(#46160): -count=1 instead of -count=2.
stderr -count=2 '^go: example\.net/lazy@v0\.1\.0
requires\n\texample\.net/requireincompatible@v0\.1\.0
requires\n\texample\.com/retract/incompatible@v2\.0\.0\+incompatible: missing
[Link] entry for [Link] file; to add it:\n\tgo mod download
[Link]/retract/incompatible$'

# There are two ways for the module author to bring the two into alignment.
# One is to *explicitly* 'exclude' the version that is already *implicitly*
# pruned out under 1.17.

go mod edit -exclude=[Link]/retract/incompatible@v2.0.0+incompatible


go list -f $MODFMT -deps ./...
stdout '^[Link]/retract/incompatible v1\.0\.0$'
! stdout 'v2\.0\.0'

# The other is to explicitly upgrade the version required under Go 1.17


# to match the version selected by Go 1.16. The commands suggested by
# 'go mod tidy' should do exactly that.

cp [Link] [Link]

go mod tidy -go=1.16


go list -f $MODFMT -deps ./...
stdout '^[Link]/retract/incompatible v2\.0\.0\+incompatible$'
! stdout 'v1\.0\.0'

go mod tidy -go=1.17


go list -f $MODFMT -deps ./...
stdout '^[Link]/retract/incompatible v2\.0\.0\+incompatible$'
! stdout 'v1\.0\.0'

go mod edit -go=1.16


go list -f $MODFMT -deps ./...
stdout '^[Link]/retract/incompatible v2\.0\.0\+incompatible$'
! stdout 'v1\.0\.0'

-- [Link] --
// Module m indirectly imports a package from
// [Link]/retract/incompatible. Its selected version of
// that module is lower under Go 1.17 semantics than under Go 1.16.
module [Link]/m

go 1.17

replace (
[Link]/lazy v0.1.0 => ./lazy
[Link]/requireincompatible v0.1.0 => ./requireincompatible
)

require [Link]/lazy v0.1.0

require [Link]/retract/incompatible v1.0.0 // indirect


-- [Link] --
package incompatible

import _ "[Link]/lazy"
-- lazy/[Link] --
// Module lazy requires [Link]/retract/incompatible v1.0.0.
//
// When viewed from the outside it also has a transitive dependency
// on v2.0.0+incompatible, but in lazy mode that transitive dependency
// is pruned out.
module [Link]/lazy

go 1.17

exclude [Link]/retract/incompatible v2.0.0+incompatible

require (
[Link]/retract/incompatible v1.0.0
[Link]/requireincompatible v0.1.0
)
-- lazy/[Link] --
package lazy

import _ "[Link]/retract/incompatible"

-- requireincompatible/[Link] --
module [Link]/requireincompatible

go 1.15

require [Link]/retract/incompatible v2.0.0+incompatible

You might also like