You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!)
The text was updated successfully, but these errors were encountered:
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.
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 thelog_dir
flag is declared twice (once for the normal dependency, and once for the dependency atvendor/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 intovendor
, excluding thevendor
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!)
The text was updated successfully, but these errors were encountered: