Handling of nested-vendoring

[ijc]

If I vendor a package which itself vendors stuff then I somehow need to ensure that I satisfy the requirements of that package.

I'll use swarmkit as an example. If I vendor docker/swarmkit into my project then I also need to pickup the contents of docker/swarmkit/vendor.conf somehow.

Before I switched to vndr I was simply dumping a copy of docker/swarmkit into vendor/github.com/docker/swarmkit, including the vendor/github.com/docker/swarmkit/vendor directory. This almost worked since go will consult vendor/github.com/docker/swarmkit/vendor while building vendor/github.com/docker/swarmkit (but not otherwise, which is quite nice for encapsulation).

However it didn't actually work because vendor/golang.org/x/net/context/ is treated as distinct from vendor/github.com/docker/swarmkit/vendor/golang.org/x/net/context/ and hence the Context objects used in my project could not be passed to Swarmkit functions (since the types don't match).

My manual solution was to "promote" (with mv(1)) the subset of packages which need to cross the API boundary from vendor/github.com/docker/swarmkit/vendor to my project's vendor dir. In practice this was a fairly small/manageable subset (golang.org/x/net, google.golang.org/grpc and github.com/golang/protobuf).

With vndr I toyed with removing the code which removes nested vendor directories, but that suffers from the type mismatch problem mentioned. There is no mechanism with vndr to promote things in the way that I was doing.

I ended up simply lifting the whole of docker/swarmkit/vendor.conf into my vendor.conf, but that's rather manual (and prone to getting out of date). I'm not sure what other way this could be handled. Some half baked thoughts:

• A way to #include a vendor.conf provided by a vendored component wholesale
• A way to say "use the version given by this other vendor.conf" as a way to "promote" things. In this case the nested-vendor directories would need to be at least partially preserved too (for all the non-promoted stuff)

Neither of those seem like perfect options though.

[LK4D4]

@ijc25 Yeah, nested vendoring is really hard :/ Trying to automate it definitely won't work for all users. I'd vote for a separate tool which can read all repos vendored files and report if you need to update.

[ijc]

Hard> Yes :-/

A separate tool seems like a reasonable solution. It might be useful to that goal to have vndr not strip the vendor.conf files out of things which it pulls in?