Reconsider go.mod structure to enable vendoring tanzu-framework without binding to kubernetes/client-go/cluster-api version.

[joshrosso]

Describe the feature request

Today, plugin authors must vendor vmware-tanzu/tanzu-framework in order to make a compliant plugin. Namely, to use the PluginDescriptor as seen in this TCE plugin.

As part of importing this package, a plugin will be bound to multiple Kubernetes-related dependencies in core. This means, should a plugin author require a different version of client-go, they may run into serious issues or need to do serious workarounds to make it work.

Is there a model where vendoring of tanzu-framework could introduce minimal transitive dependencies to a plugin-project?

Describe alternatives you've considered

Alternatively, tanzu-framework could take a stance where plugin developer must be bound to the same Kubernetes-related dependencies as the plugins found in this repository.

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context

[iancoffey]

"This is breaking physics", this is a long term effort. We need to depend on client-go and we have little leeway there.

[joshrosso]

We need to depend on client-go and we have little leeway there.

@iancoffey, not sure I understand the response. This issue isn't proposing we don't depend on client-go?

So the decision is that anyone depending on tanzu-framework must use the same version of client-go (and any other dependencies for that matter)?

[iancoffey]

@joshrosso Pardon, my comment was made during the SIG meet and lacked context for sure. Result was just that we need to prove viability and also set expectations that this is a long term goal with hurdles to clear first.

[iancoffey]

Lets see if this is technically possible and if so, document and propose the change.

If not feasible, lets close this.

[stmcginnis]

Wouldn't this be possible with moving the PluginDescriptor struct into its own submodule? Then plugins would only need to import that module, and not pull in the entirety of tanzu-framework.