go mod friendly #3031
Comments
|
SGTM (but let's wait for Go 1.12 GA) |
|
yup, using go v1.12 setting the |
Go 1.12.x has been GA for a while. Can we get a resolution to this? Causing some dependency hell here, thx. |
|
Also breaks with 1.2.8. |
|
Still broken with 1.2.9 - can confirm that changing to |
|
Seems to still be broken with 1.3.0, if this error is related: $ go get github.com/moby/buildkit
go get: github.com/moby/buildkit@v0.6.2 requires
github.com/containerd/containerd@v1.3.0-0.20190507210959-7c1e88399ec0: invalid pseudo-version: version before v1.3.0 would have negative patch number
If it helps anyone, I was able to workaround it with the following in So looks like a beta 1.3.0 works fine. |
|
@imiric Not sure how you got this to work, but def broken for me. @scottshotgg can confirm this worked for me |
|
Go mod doesn't work well with repositories that use release branches; 1.3.0-beta.2 was the last beta tagged from master, after which the |
@thaJeztah It looks like this was an intentional change: Edit: Actually that commit seems unrelated; I guess it's another one of the commits seen in pingbacks in golang/go#27173 |
|
Any update on this? I'm still affected using go 1.13.4. |
|
Added check list to the top comment of this issue for tracking the progress across github.com/containerd repos. Help wanted. |
|
Still wondering how we'll deal with versioning. While this repository has SemVer tags, those tags apply to the binary releases, not to the Go API. The Go client API is explicitly called out as "unstable", and therefore many projects use a specific version from master (which could be problematic if Go mod prefers tags over master). While there is an intent "to stabilize the API in a future release", it's possible that changes to that API (interfaces/signatures) may follow a different cadence than the releases; should separate tags be used for Go, or should they be in lock-step with the containerd releases themselves? |
|
I think we have never broken Go API in patch releases (correct me if wrong). |
Agreed, I don't think patch releases (vX.Y.Z) broke compatibility, but minor releases may definitely not have been minor from the API perspective (at least, I'm not sure if that has been carefully looked at with each change). |
|
Agreed. Seems like it may be good to agree of a certain major & minor version of golang we should use to be consistent. |
It is "recommended strategy", but we don't need strictly adhere to? Anyway, we are trying to do our best to establish Go API stability in 1.4 (#3554 ). |
|
I seem to be getting an error with [[constraint]]
name = "github.com/containerd/containerd"
version = "1.2.0"
[prune]
go-tests = true
unused-packages = trueI get the same if I bump to the latest version - https://github.com/containerd/containerd/releases/tag/v1.3.2 |
|
@alexellis it currently depends on a version of docker/distribution from master having this commit: distribution/distribution@0ac367f (the 1.3.2 branch is using this commit: https://github.com/containerd/containerd/blob/v1.3.2/vendor.conf#L59).
For now, you can add an override/constraint to your Gopkg.toml to pin the dependency to the same commit as the 1.3.2 version (distribution/distribution@0d3efad) |
|
Mixing up Can we soon finish migrating the entire stuff to |
|
Thanks @thaJeztah |
|
Based on this tweet from @ibuildthecloud, it looks like once CRI starts to vendor in k8s 1.17, it gets a lot less messy to use go mod. Maybe @Random-Liu can say when they are ready to move up the CRI project deps and then we can vendor that back in and move to 1.17 and be ready to fully switch to Edit: A bit more detail here |
|
For the release-branches issue, how about tagging 7f9530d (I think that's the first commit after release/1.3 branched) as Then transitive dependency resolution would pick the correct newer (master) version, over older (branch) versions. This is assuming I'm correct, and the problem affecting consumers like buildkit is not that they want to tie to a tag, but that when multiple versions are visible, it's resolving a commit with most-recent-ancestor tag of v1.3.2 (i.e. release-branch), instead of a commit that's from master but has a SemVer-older most-recent-ancestor tag of 1.3.0-beta.2. It would also prevent users reading their go.mod, seeing 1.3.0-beta.2 (for a master commit) and trying to "upgrade" that to v1.3.2, and wondering why APIs have disappeared. |
|
Running a basic app still fails: package main
import (
"log"
"github.com/containerd/containerd"
)
func main() {
client, err := containerd.New("/run/containerd/containerd.sock")
defer client.Close()
}with the following error: |
|
@gun1x try the following require(s) in your go.mod |
|
That worked. it would help to have stuff like this in the docs here: https://github.com/containerd/containerd/blob/master/docs/getting-started.md |
|
@Random-Liu One of the significant issues of moving to go.mod is that CRI uses the streaming server from k8s.io/kubernetes. Is there any effort to move the streaming server to k8s.io/streaming-server or something similar? Until this happens go.mod in containerd will be a real headache. |
|
Any updates here? Thanks! |
|
dims moved the streaming code... and we are merging cri into containerd... and containerd/cri#1377 (comment) |
|
It looks like go.modBut I notice some dependencies are bumped. And it seems that the release-tool needs update too. |
|
@zhsj thanks for testing out. I have tried to make updates in release-tool to better handle the difference representation in dependencies. If you are seeing issues please file it over there. I want to get those fixed early so we don't have that as a headache if we pull go mod into the next release. |
|
Completed in #4760 |
and others
https://github.com/containerd Subproject checklist (EDIT: added by @AkihiroSuda )
Description
Containerd currently causes issues for downstream projects using
go mod. Since this is the official Go dependency management tool now, support would be nice.Steps to reproduce the issue:
go modfor dependency management.Describe the results you received:
Does not build. Specifically due to the following.
Module based builds were actually working fine until this commit ed756ff which introduced a dependency on code that is only in the master branch of docker/distribution.
As a workaround we currently use
in our go.mod file. But this is not really maintainable and also slows down built time significantly as it requires re-download of certain modules on every build.
Describe the results you expected:
Project builds.
Output of
containerd --version:Thanks
The text was updated successfully, but these errors were encountered: