Don't vendor dependencies for plugins ?

[rhuss]

We have different dependency declaration for different plugins which is a good thing to keep them self-contained and independent (allowing also for an independent release cycle).

However, verndoring the dependencies is really huge, especially for source where each source support for sources from eventing-contrib would have to vendor eventing-contrib individually although it only needs the client bindings for a single source out of it. (I wonder whether we could craft go mod that way to only pick that client dependency ?)

One suggestion for this particular dependency would be to get the client API with different means (e.g. git clone directly, by cherry-picking the client interface)

However, I would discuss in general whether for an aggregated repository vendoring makes sense at all or whether we should use go mod without a vendor/ dir and using the local go mod cache for downloading dependencies ?

[rhuss]

@maximilien @daisy-ycguo @zhangtbj @zhanggbj What are your opinion in this ? I think this will help considerably in avoiding duplicated dependencies and download times as the shared cache below $GOROOT would be used.

[zhangtbj]

Yes, I think if we keep the vendor in each plugin and if we have more and more plugins, the size of the repo will very large and even hard to pull the repo.

I also agree to remove the vendor in each plugin.

[zhanggbj]

@rhuss
We do have some difficulties to pull vendor packages considering our network situation... but I support to use go mod without /vendor which it is going really huge both for the repo and each plugin, so 👍 for my side.