Hey all,

As you know, we're starting to look at consuming containerd in Garden, instead of talking to runc directly, but we're running up against some problems, and I was hoping to start a discussion around this.

Up to now in Garden, we've happily been building our own specs.Spec from the runtime-spec and letting runc consume it from config.json. It would the best if we could simply pass the spec we've already generated to the containerd client NewContainer() method via containerd.WithSpec() (

However, since containerd vendors the runtime-spec library itself, we end up with Go compilation errors because of the conflicting packages (our gopath, and containerd's vendored libs). I imagine you are vendoring because you want to pin versions and be able to build the binaries, and that makes sense but it makes consuming the library a little difficult.

I might be totally missing some trick here, and it'd be great if that were true but I only see a few options for us here:

1. Fork containerd and maintain a fork without vendored libs (yikes)
2. Figure out whether the vndr dependency management tool you are using can handle vendored directories in the same way that dep supposedly does, and move over? (ugh, even if it works)
3. Move ourselves to use dep for all of eternity, which might work with no changes to containerd? (no thanks)
4. PR to separate the containerd library from the runtime? (sad, not sure if it's possible)

I feel like I must be missing something here, since other projects must be consuming containerd, it'd be great if you could point me in the right direction!

Thanks,

Will