When fetching a dependency, automatically remove their vendor/

[tarnfeld]

Sometimes when importing code from external applications, they have committed the vendor/ folder. Perhaps they didn't intend use as a library, but you'd still like to import some code of functions.

In this case, it's possible to see type/interface errors with return values because code inside the dependency will use their version of the interface, and code outside will not. When installing a dependency, could we automatically look for the vendor/ folder, and delete it?

[jchv]

I agree with this. I'm currently using multiple packages per repository and it's hard to picture how vendoring may impact this. To exemplify why it's a hard case, think of it this way: two repositories may well depend on eachother so as long as there's no circular dependencies between packages. Thus, two repositories could theoretically vendor each-other. While this can (and in many/most/all? cases, should) be solved by splitting repositories up, it's still an interesting case that works nearly perfectly with traditional go get. But if both projects are using vendoring, they could land in each other's vendor folders.

A sane solution to this would be to flatten all vendoring intelligently, or just delete the entire vendor folder and treat it as if there was no vendor folder as proposed here.

(Note: I haven't tried any of this due to my concerns, so some of them may well be invalid.)

[peter-mogensen]

I think there's very good arguments for never having libraries vendor code.
https://peter.bourgon.org/go-best-practices-2016/#dependency-management
If something is not a library and does vendor and you want to use it as a library, I'd say there's a conflict you have to resolve manually.

[philwinder]

I've just hit this issue with gvt, and is exactly why I recommend glide over gvt, because that has a -v option that is able to flatten sub-dependencies.