Admittedly I don't know what the real root cause is, but bumping the version and running go mod tidy generally should never do harm, so I thought why I not do that. 🤷🏻
For context, with the existing go.mod, running go mod tidy results in a really confusing output mentioning Go 1.16 for some reason. I have no idea why / where that comes from, as I was running this w/ go version go1.19.3 darwin/arm64 and the constraints are set to 1.17.
github.com/hashicorp/syntax/builder imports
github.com/hashicorp/go-multierror loaded from github.com/hashicorp/go-multierror@v1.0.0,
but go 1.16 would select v1.1.0
github.com/hashicorp/syntax/builder imports
github.com/mitchellh/cli imports
github.com/armon/go-radix loaded from github.com/armon/go-radix@v0.0.0-20180808171621-7fddfc383310,
but go 1.16 would select v1.0.0
github.com/hashicorp/syntax/builder imports
github.com/mitchellh/cli imports
github.com/posener/complete loaded from github.com/posener/complete@v1.1.1,
but go 1.16 would select v1.2.3
github.com/hashicorp/syntax/builder imports
github.com/mitchellh/cli imports
github.com/posener/complete/cmd/install loaded from github.com/posener/complete@v1.1.1,
but go 1.16 would select v1.2.3
github.com/hashicorp/syntax/builder imports
github.com/mitchellh/cli imports
github.com/posener/complete imports
github.com/posener/complete/cmd loaded from github.com/posener/complete@v1.1.1,
but go 1.16 would select v1.2.3
github.com/hashicorp/syntax/builder imports
github.com/mitchellh/cli imports
github.com/posener/complete imports
github.com/posener/complete/match loaded from github.com/posener/complete@v1.1.1,
but go 1.16 would select v1.2.3
github.com/hashicorp/syntax/builder imports
github.com/spf13/viper imports
github.com/spf13/viper/internal/encoding/yaml imports
gopkg.in/yaml.v2 tested by
gopkg.in/yaml.v2.test imports
gopkg.in/check.v1 loaded from gopkg.in/check.v1@v0.0.0-20161208181325-20d25e280405,
but go 1.16 would select v1.0.0-20190902080502-41f04d3bba15
To upgrade to the versions selected by go 1.16:
go mod tidy -go=1.16 && go mod tidy -go=1.17
If reproducibility with go 1.16 is not needed:
go mod tidy -compat=1.17
For other options, see:
https://golang.org/doc/modules/pruning
This aims to resolve the large diff problem exhibited in the following dependabot PRs by bumping the Go version and running
go mod tidy
:Admittedly I don't know what the real root cause is, but bumping the version and running
go mod tidy
generally should never do harm, so I thought why I not do that. 🤷🏻For context, with the existing
go.mod
, runninggo mod tidy
results in a really confusing output mentioning Go 1.16 for some reason. I have no idea why / where that comes from, as I was running this w/go version go1.19.3 darwin/arm64
and the constraints are set to1.17
.