2

I want to require a certain version of a Go package that has not yet been converting to using modules, I want to require this in my go.mod file. Specifically, the package is "github.com/docker/docker/pkg/system@v19.03.13"

When I run the following command, I get the following output:

$ go get -v github.com/docker/docker/pkg/system@v19.03.13
go: found github.com/docker/docker/pkg/system in github.com/docker/docker v17.12.0-ce-rc1.0.20200916142827-bd33bbf0497b+incompatible

As you can see, the version v17.12.0-ce is downloaded, not v19.03.13. I did also notice the "+incompatible" suffix, but I am not sure that has anything to do with the issue. According to the docs

the go command adds an +incompatible suffix to versions with major version 2 or higher without a go.mod file. +incompatible indicates that a version is part of the same module as versions with lower major version numbers; consequently, the go command may automatically upgrade to higher +incompatible versions even though it may break the build.

so I understand that this package does not have a go.mod file, however the downloaded version (17.x) is greater than 2, so I don't think +incompatible is the issue.

my question is: When I specify version v19.03.13, why does Go install v17.12.0-ce?

This is the version I want to use

This is the one that is downloaded

northsideknight
  • 1,519
  • 1
  • 15
  • 24
  • 2
    The version doesn't matter, since it's not a module and is generating a synthetic version based on the best guess of the parent tree. Look at the commit id, and you'll see you're also getting the latest commit from `v19.03.13` – JimB Oct 01 '20 at 15:01
  • hey @JimB , good eye, do you want to add this as an answer and I can mark it correct? – northsideknight Oct 01 '20 at 15:21

1 Answers1

3

The version listed in the go.mod pseudo-version does not matter for repositories that are not go modules. The version v19.03.13 is not a syntactically valid semantic version, so the go tool will walk up commit tree to find one, and the first valid semver it encounters happens to be v17.12.0 (which is not intended to be a semantic version, but it is at least valid). The fact that the leading version isn't what is expected in the pseudo-version isn't a problem as long as go itself can reproduce and parse the result.

If you look at the trailing commit hash, you have bd33bbf0497b, which is the correct commit id for the v19.03.13 tag.

JimB
  • 104,193
  • 13
  • 262
  • 255
  • `v19.03.13` is not used as the pseudo-version base because it is not syntactically valid as a [semantic version](https://semver.org/). – bcmills Feb 17 '21 at 15:23
  • Unfortunately, `v17.12.0-ce-rc1` is syntactically valid as both a semantic version and a [calendar version](https://calver.org/). In the Docker repo it is intended as the latter, but the `go` command interprets it as the former. – bcmills Feb 17 '21 at 15:25