Changes to SinkFlags in order to support plugin event sources

[daisy-ycguo]

Description

Make two changes to SinkFlags in order to support other event sources at client-contrib.

Changes

• Add a public method SinkToDuckV1Beta1 to flags package.
• Change the parameter in SinkFlags.Add() to flag.FlagSet, similar as AddNamespaceFlags().

[rhuss]

Sorry, I thought I already sent the review (but probably forgot to push the button).

I don't think that anything from client-contrib must depend on client, as this would also couple the release cycle of otherwise independent plugins to the client release cycle.

Especially when the reuse is only marginally, its better to duplicate for the plugins to make plugins self-contained and independent.

As this, I don't think we should merge this PR.

/hold

[rhuss]

Its not really a Sink but a Destination what you are converting (could be used for other destinations than sinks).

I would it call it ToDuckV1Beta1 as Destination is already clear from the signature, (alternative: DestinationAsDuckV1Beta1 if we want to be more verbose)

[maximilien]

/ok-to-test

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: daisy-ycguo, maximilien

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [maximilien]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[knative-metrics-robot]

The following is the coverage report on the affected files.
Say /test pull-knative-client-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/kn/commands/flags/sink.go	57.6%	54.3%	-3.3
pkg/kn/commands/source/apiserver/apiserver.go	62.5%	59.1%	-3.4

[maximilien]

I don't think that anything from client-contrib must depend on client, as this would also couple the release cycle of otherwise independent plugins to the client release cycle.

While I would agree with the point of having common code in a separate repo, perhaps client-pkg to avoid some of the dependency issues. I also have to question this a bit since part of the charter for kn is to have code that can be reused to create “custom” clients. This has been a goal from the start and we are finally testing this now with plugins.

So while I like the idea of extracting some code for common packages, I also think we need to figure out a way to allow exported types and code to be usable for external components. These “users” would simply vendor the version of the client that they need and periodically update and resolve conflicts.

[rhuss]

@maximilien I get you point, so let's look for an smaller, not-optimal solution as long as its still hard to introduce new repositories.

If separation of client-internal and exported libraries can not be enforced by using different dependencies (or GitHub repos), we should at least base that separation on Golang package level and maybe even reflect it in the directory structure (e.g. introducing a top-level directory for code that is meant to be reused). Only relying on the golang idiom of uppercase types for exported functionality is not good enough for us (i.e. there are cross-package dependencies whithin the client which are not meant to used outside as the can arbitrarily be changed).

Having this clear seperation even within the knative/client repo has also the benefit that it could be easily moved out into a seperate Github repo later, and we can increase the review standards for those exported code.

The candidates for exported functionalities that I see are:

• The client services
• Flag parsing
• Watch functionality

Anything else ?

So I would suggest to introduce eg. lib directory for this kind of code (I would use pkg but that is already taken).

@daisy-ycguo would this work for you ? If so, I would pick up your PR and include it in a separate PR for setting up this structure.

[maximilien]

The candidates for exported functionalities that I see are:

• The client services
• Flag parsing
• Watch functionality

Good.

Anything else ?

The e2e test infrastructure as well as some parts of the UT code.

Let's start with that and I am sure lots more will come up.

So I would suggest to introduce eg. lib directory for this kind of code (I would use pkg but that is already taken).

Sounds good.

[daisy-ycguo]

I will close this PR since dr.max has tracked it with the issue #763. Thank you for the comments and discussions.