search

knative / client-contrib

Community contributed `kn` plugins.
Apache License 2.0
10 stars 23 forks source link

Move http://github.com/maximilien/kn-source-pkg to this repo as a library? #56

Open daisy-ycguo opened 4 years ago

daisy-ycguo commented 4 years ago

@maximilien @rhuss let's use this issue to discuss where we shall put maximilien/kn-source-pkg.

maximilien/kn-source-pkg could be used as a common package for all event sources plugins, which will ease the development of sources plugins. Now it's still under dr.max's personal repo. The kn-source-pkg is also a separate go project and shall be built dependently.

Can we move it to this repo as a library? Which folder shall we put it? Maybe put to client-contrib/common. Let me know your thoughts. Thank you.

rhuss commented 4 years ago

I suggest to move the code from the "pkg" directory (but probably only this ?) into a top-level "shared/sources" directory. When we should decide to split up everything in separate repos we can strive for a "knative-sandbox/kn-plugin-source-pkg" repo which then can hold the full code from https://github.com/maximilien/kn-source-pkg

wdyt ?

maximilien commented 3 years ago

I think the knative-sandbox/kn-plugin-source-pkg repo makes a lot of sense to me. Let's do this soon as you are done with #73. Or I can start process now if you are all OK?

cc: @rhuss @daisy-ycguo

maximilien commented 3 years ago

/assign @maximilien

navidshaikh commented 3 years ago

I think the kn-plugin- prefix to be used for only plugins and not for common code per our discussion? The idea was to make clear distinction between plugin, common code, arbitrary repos by the repo name themselves, knative-sandbox/source-pkg fits the bill IMO.

rhuss commented 3 years ago

Late to the game again (sorry) but I think we should collect all shared code in a client-pkg, and put this even into the knative organisation. This would not only include the code that is useful for creating sources, but also the client API, command option parsing libraries in general and anything else that would make sense to be used by a plugin.

That way we would avoid a too fine granular splitting of support libraries and we break the cyclic dependency between kn and kn plugins

maximilien commented 3 years ago

https://github.com/knative-sandbox/kn-plugin-source-pkg

rhuss commented 3 years ago

Thanks @maximilien ! This is a good first step, for the future we might consider to combine this sandbox repo with a knative/client-pkg that holds the code that can be shared between the client and its plugins (like parsing opptions, etc). Then the source specific shared library would be a good fit for the repo, too.

E.g. when then would have a dependency tree of:

@maximilien wdyt ?