⚠ Re-organize pkg/plugin directory

[Adirio]

Description

Re-organize pkg/plugin directory with the following scheme:

• pkg/plugin: interfaces and types for plugins and helper methods
• pkg/plugins: kubebuilder defined plugins, one per directory
• pkg/plugins/internal: templating and file system interaction machinery used for kubebuilder plugins
• pkg/plugins/base: base plugin with qualified name "go.kubebuilder.io" ("go" can't be used as a package name, therefore "base" has been used)

It also deletes the pkg/plugin/scaffold.Scaffolder interface that was not being used.

Motivation

Currently, the base plugin is placed directly inside the pkg/plugin folder. As new plugin ideas arise (the plugin implementation of addon, #1803, ...) a better organization for plugins is required. With this new approach, these new plugin ideas can be deployed in the pkg/plugins directory (pkg/plugins/addon, pkg/plugins/deployment, ...).

Comments to reviewers

Despite being markd as size/L, this PR is pretty small:

• 98/121 file changes are just location changes with no single LoC modified.
• 17/23 remaining file changes are just import updates to reflect those new locations.
• The four remainign file changes are moving the const DefaultNameQualifier = ".kubebuilder.io" declaration to the pkg/plugins directory so that all plugins use this domain to qualify their names.

[Adirio]

@camilamacedo86 this PR should enable the creation of the plugin we were talking about in #1803. It also deletes the Scaffolder public interface that we were not using, as it is already a breaking change that requires changes in the projects that use kubebuilder as a library, I figured it is a good place to do it.

[camilamacedo86]

pkg/plugins/base: base plugin with qualified name "go.kubebuilder.io" ("go" can't be used as a package name, therefore "base" has been used)

I have been thinking in a base plugin for while but IMO it would be only the config files. I mean, would not have any go/language scaffold at all and would only have the init config setup that is common for any language. So, I am not sure if we should move forward with this change.

I understand that you are trying to find a better design/approach for we move forward with the EP: #1803 and it is very appreciated. However, in POV we can move forward with that as a subcommand or in the max as a new plugin to add this value to the tool and then, cleanup/change it accordingly after the plugin phase 2 be in place.

In POV has no need to block any improvement/RFE that add good values in the project and we can address needs/requirements such this one in the most simple/straightforward way at the first moment only for v3-alpha and then, change it in the future after plugin phase 2 be implemented and we have a better idea over how it would be. Let's step by step.

[Adirio]

pkg/plugins/base: base plugin with qualified name "go.kubebuilder.io" ("go" can't be used as a package name, therefore "base" has been used)

I have been thinking in a base plugin for while but IMO it would be only the config files. I mean, would not have any go/language scaffold at all and would only have the init config setup that is common for any language. So, I am not sure if we should move forward with this change.

I don't know if a plugin which only scaffolds config files will be a nice fit or not, thats a separate discussion. The name "base" is only used as a directory name, it can be changed in the future if we consider there is a more "basic" plugin. The thing is that this plugin ("go.kubebuilder.io") can't be placed in a directory called go becasue "go" is not a valid package name. The point is, it is just a name.

I understand that you are trying to find a better design/approach for we move forward with the EP: #1803 and it is very appreciated. However, in POV we can move forward with that as a subcommand or in the max as a new plugin to add this value to the tool and then, cleanup/change it accordingly after the plugin phase 2 be in place.

This PR is exactly for that. To implement it as a new plugin. You create a pkg/plugins/deployment directory for example and you implement the plugin there. It just organizes things in directories not to have multiple plugins in the same directory.

In POV has no need to block any improvement/RFE that add good values in the project and we can address needs/requirements such this one in the most simple/straightforward way at the first moment only for v3-alpha and then, change it in the future after plugin phase 2 be implemented and we have a better idea over how it would be. Let's step by step.

I don't understand what you mean by block. This is just moving files from one directory to another, it doesn't block anything. It doesn't require phase 2.

[estroz]

/retest

[estroz]

I was thinking about doing something similar myself. The only non-blocking suggestion I have is pkg/plugins/base -> pkg/plugins/golang, although I don't know if the language distinction is important in kubebuilder since all plugins for the foreseeable future will scaffold Go code.

/approve

[Adirio]

I was thinking about doing something similar myself. The only non-blocking suggestion I have is pkg/plugins/base -> pkg/plugins/golang, although I don't know if the language distinction is important in kubebuilder since all plugins for the foreseeable future will scaffold Go code.

Done, just needs lgtm

[camilamacedo86]

After one out from the base to golang it shows OK for me.
We might able to have base and golang after phase 2 be in place in order to support other languages/types.

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Adirio, camilamacedo86, estroz

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 [camilamacedo86,estroz]

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

[estroz]

/retest