Move from "external" to "vendor" folder.

[kardianos]

By putting dependencies into the "vendor" folder, it will allow packages that import this package to use sub-packages as well without risk of duplicating imports.

The functional change would be to rename "external" to "vendor", remove the import path rewrites, then (for go1.5) set GO15VENDOREXPERIMENT = 1. Due to third party package use, this may not be viable until go1.6 comes out (no env flag required) or 1.7 (where it becomes standard).

[bufdev]

We actually did the reverse of this for the opposite reason heh #338 #339 #348 #349

[kardianos]

Haha.. True, the "vendor" folder is now special and doesn't mix with import path rewriting. I've got nothing against import path rewriting.

Suggestion still stands (probably for a future date) to move (back) to the vendor folder and remove import path rewrites. This will allow package to reference both your dependencies and their own, even when the canonical package path is the same (it allows tools to flatten the directory structure tree).

[bufdev]

Ya for sure haha. I think this library wants to be backwards compatible for now, especially as vendoring is still done with GO15VENDOREXPERIMENT. But ya, agree haha :)

[shoonoise]

Any updates? BTW, go 1.6 use vendor by default.

We use vendoring feature from 1.6 and have got libs duplication (e. g. /vendor/github.com/fsouza/go-dockerclient/external/github.com/Sirupsen/logrus and /vendor/github.com/Sirupsen/logrus) it very it very annoying our team.

[fsouza]

@shoonoise using the vendoring experiment does not "solve" the duplication. It isn't an actual problem, as the library may depend on a different version of logrus. So you'd still have two logrus, but one would be inside go-dockerclient/vendor instead of go-dockerclient/external.

I have been using the vendor experiment since Go 1.5 in other projects, I'm still not comfortable to drop both Go 1.3 and Go 1.4 in go-dockerclient.

[shoonoise]

@fsouza so do you think that each lib should brings all their dependencies with self?

[bufdev]

@fsouza @shoonoise @kardianos I would recommend we wait until 1.7 to consider this - it's still non-standard, and yes the golang community upgrades quickly, but I think supporting 2 versions prior is appropriate for a library like go-dockerclient. When 1.7 comes out, then 2 versions prior will be 1.5, and then at least you can handle this with GO15VENDOREXPERIMENT=1

[bufdev]

@shoonoise the original intent of this was that it was a highly-requested feature for go-dockerclient. Many users of go-dockerclient do not use github.com/docker/docker directly, but go-dockerclient does, and docker is a large repository. So when building docker images, for example, having to do go get on github.com/docker/docker each time was really time consuming.

[fsouza]

Vendoring is here! Kinda...