Removes conflicting versions of containerd/containerd dependency

[antonio-osorio]

Addresses the following error when depending on buildkit:

go: github.com/moby/buildkit@v0.6.3 requires
	github.com/containerd/containerd@v1.4.0-0.20191014053712-acdcf13d5eaf: invalid pseudo-version: version before v1.4.0 would have negative patch number

Which otherwise requires the workaround of having the require statement:

replace github.com/containerd/containerd => github.com/containerd/containerd v1.3.1-0.20200227195959-4d242818bf55

in importing libraries.

** Note: this change does not modify the dependency version used, the same version (1.3.1) is loaded on the vendor folder by go mod vendor. Version 1.4.0 does not exist

[thaJeztah]

This change is targeting master, but you're using buildkit v0.6.3, which is on another branch, and which expects a different version of containerd; https://github.com/moby/buildkit/blob/v0.6.3/go.mod#L12

[antonio-osorio]

Checking again master seems to have the same issue:

containerd-issue antonio$ ls
go.mod

containerd-issue antonio$ cat go.mod
module example.com/m

go 1.14

require github.com/moby/buildkit master

containerd-issue antonio$ go mod vendor
go: github.com/moby/buildkit@v0.7.1-0.20200402081307-6f28b0d70b97 requires
	github.com/containerd/containerd@v1.4.0-0: reading github.com/containerd/containerd/go.mod at revision v1.4.0-0: unknown revision v1.4.0-0

containerd-issue antonio$ cat go.mod
module example.com/m

go 1.14

require github.com/moby/buildkit v0.7.1-0.20200402081307-6f28b0d70b97

[antonio-osorio]

Regarding the v0.6.3. It is a bit misleading because I am using a fork and that was the last tag that synced.. but it the code has since been synced to moby/buildkit master. :(

[thaJeztah]

There was some discussion about this in #1376 (comment)

@tonistiigi @AkihiroSuda PTAL

[tonistiigi]

#1297 has some details on this.

Since go1.13 , go broke the ability to correct the detected version number for a commit if the gomod gets it wrong. That means that for projects that use release branches can't be imported from master branch without replace rules. We can't use the automatically detected v1.3.1 prefix for contained as then if you would import buildkit and some other module would also depend on actual release build of contained (eg. current latest v1.3.3) gomod would sort the modules wrong, thinking v1.3.3 is newer and breaking buildkit because it depended on master branch features that are not in v1.3.3.

That means that for now when you want to import buildkit with go.mod you need to copy the replace rules buildkit uses to your go.mod file as well

buildkit/go.mod

Lines 81 to 83 in 195f9e5

	replace github.com/containerd/containerd => github.com/containerd/containerd v1.3.1-0.20200227195959-4d242818bf55
	replace github.com/docker/docker => github.com/docker/docker v1.4.2-0.20200227233006-38f52c9fec82

I know this is really crappy solution and I'm really sad go decided to break all these projects (with no justification afaik) but this is out of our control.

[thaJeztah]

Should we add a comment in the go.mod to describe that?

[antonio-osorio]

one caveat of the solution proposed is that the project that depends on buildkit, either directly or transitively, will need to monitor for changes in the buildkit/go.mod file.

Otherwise it will remain pinned at the version that was current during the first time the user encountered the problem.

[tonistiigi]

one caveat of the solution proposed is that the project that depends on buildkit, either directly or transitively, will need to monitor for changes in the buildkit/go.mod file.

Yes, this definitely has problems as well and we wouldn't do it if there was another way.

Closing this for now. We should definitely add docs for how to depend on buildkit packages and how to update go.mod though.