Skip to content
This repository has been archived by the owner on Mar 9, 2021. It is now read-only.

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

Open
daisy-ycguo opened this issue Jun 24, 2020 · 7 comments
Assignees

Comments

@daisy-ycguo
Copy link
Member

daisy-ycguo commented Jun 24, 2020

@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
Copy link
Contributor

rhuss commented Jun 24, 2020

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
Copy link
Contributor

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
Copy link
Contributor

/assign @maximilien

@navidshaikh
Copy link
Contributor

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
Copy link
Contributor

rhuss commented Oct 20, 2020

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
Copy link
Contributor

@rhuss
Copy link
Contributor

rhuss commented Dec 1, 2020

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:

  • knative/client -> knative/client-pkg
  • knative-sandbox/kn-plugin-something -> knative/client-pkg
  • knative-sandbox/kn-plugin-source-kafka -> knative/client-pkg (which then also contains the source specific shared code)

@maximilien wdyt ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants