Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependencies with vendor directories #13

Closed
justinsb opened this issue Aug 27, 2016 · 1 comment
Closed

Dependencies with vendor directories #13

justinsb opened this issue Aug 27, 2016 · 1 comment

Comments

@justinsb
Copy link

Some dependencies (for example kubernetes) include a vendor directory themselves. However, this causes the same code to be imported twice if I am also using the same dependency in my project.

Sometimes this double-import problem is problematic - for example github.com/golang/glog logs a warning, because the log_dir flag is declared twice (once for the normal dependency, and once for the dependency at vendor/k8s.io/kubernetes/vendor/github.com/golang/glog/

Is there a workaround you can recommend?

Before I discovered vendetta, I had been manually managing my dependencies as git submodules, putting them into _vendor, and then rsyncing them into vendor, excluding the vendor directories of all vendored packages. A huge downside of this is that I then need to manage the dependencies of my dependencies (i.e. add submodules for each of them) - if vendetta could help with that it would be wonderful.

Perhaps a flatten option to get rid of the busywork (I'm very happy to manually resolve conflicts!)

@dpw
Copy link
Owner

dpw commented Aug 31, 2016

Hi. You are right that the consequences of the same code existing twice can be problematic.

Another common manifestation of the same underlying problem is where two types with the same name in the source code are considered distinct by the go compiler (because they originate from under different vendor directories). The resulting compiler errors about conflicting types can be hard to understand when you see them for the first time.

As use of the golang vendor support has become more widespread, so has awareness of these issues. But I haven't yet seen a good proposal for what should be done about them. And I'm afraid I don't have a recommendation that works with vendetta.

Some people have proposed the rule that libraries shouldn't vendor their dependencies. The problem with that is that there's no sharp division between libraries and non-libraries. Many projects can stand on their own of be used as a dependency of another, e.g. k8s.

In your case, and as golang's vendor support stands, the only solution is to transplant glog from vendor/k8s.io/kubernetes/vendor/github.com/golang/glog/ up to vendor/golang/glog (being sure to keep the same version of glog that k8s bundles). But this means that you can't have vendor/k8s.io/kubernetes/ be a submodule, because you can't modify a submodule in that way. Which means that vendetta, in its current form, is not applicable.

If there was some way to make vendetta handle this issue, I'd be delighted, but it doesn't seem possible.

Vendoring tools which use the copying approach are in a better position. I'm not sure if any of them have strong support for this kind of flattening operation yet though.

@dpw dpw closed this as completed Aug 31, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants