⚠️ [Rename] Disambiguate plugin by calling subcommand what the plugin getters returns instead of plugin

[Adirio]

Description

Rename plugin getters return objects to Subcommand.

Motivation

Currently, both the structs with the getters and those returned by them are called "plugin" (Plugin -> Plugin), leading to missunderstandings. In order to clarify which is which, one of them should be renamed. There are two possibilities:

1. Rename the struct with the getters to something like PluginFactory: PluginFactory -> Plugin
2. Rename the returned type to something like Subcommand: Plugin -> Subcommand

The word "plugin" is already extensively used in the code (comments, variable names, ...) to refer to the left term, so I figured that it would be easier to go for the second option.

When deciding which name to use, I saw how the base class for the right term structs was already GenericSubcommand and it basically represents that, with methods to bind flags and execute the command, so I opted for Subcommand.

[Adirio]

@estroz We talked about this yesterday, what do you think of this approach?

[camilamacedo86]

Hi @Adirio,

The plugins design whcih was introduced following the concept of a Plug-in Architecture. Then, it means that operations can be extending whcih allows other tools to use 1..N plugins as also they have its own plugins.

Then, the next step that we have been discussed is the plugin phase 2 which has the purpose to allow us to aggregate and/or customize the plugins. For example, we might have a plugin to it the project that will do a scaffold with a layout A and also another one which will create a project with a layout B and both can be used.

See here how the SDK CLI call all plugins currently. Note that in the PROJET file we write all plugins that were used to generate the files. (currently, we have just: go, ansible., helm). For a further understand and follow up this WIP see; #1378. Note that an EP will be raised based on the discussions made on this issue as well.

In this way, I'd like to recommend you first raise an EP and/or at least an issue where you will describe: what is the problem with the current design that you would like to solve? What are the user stories that you would like to address E.g As a <role> I can <capability>, so that <receive benefit>? Describe the technical details with examples of usage as well whcih clarifies your motivations and ideas?

By looking at the PR shows that you are changing the plugins for each one be describe as subcommand then, it shows that goes against the purpose and architecture adopted for it. However, your motivations might not be very clear to me. So, could you please raise this issue and provide the info described above?

[Adirio]

Hi @camilamacedo86,

This PR follows the same design you mention, it is just a rebranding or name change.

To refer to these names I'm going to use the X -> Y notation, where the term in the left (X) is the struct that has the GetXxxxxPlugin methods and the term in the right (Y) is the struct returned by these methods.

Right now, both are called Plugin (Plugin -> Plugin). I was talking with @estroz and having both with the same name leads to missunderstandings, so we thought that one of them should be renamed (just changing the name, the implementation and design behind it stays the same).

There are two options:

1. Changing the left term: SomethingElse -> Plugin
2. Changing the right term: Plugin -> SomethingElse

The word "plugin" is already extensively used in the code (comments, variable names, ...) to refer to the left term, so I figured that it would be easier to go for the second option (Plugin -> SomethingElse).

When deciding which name to use, I saw how the base class for the right term structs was already GenericSubcommand and it basically represents that, with methods to bind flags and execute the command, so I opted for Subcommand (Plugin -> Subcommand).

Is the motivation of these change (just renaming) clearer now?

P.S.: during the offline discussion with @estroz, the possibility of using PluginFactory -> Plugin was also mentioned.

[estroz]

These name changes make sense to me on a high level. Haven't thoroughly gone through this PR yet.

[camilamacedo86]

Hi @Adirio,

So, by reading your comment in #1748 (comment) I understand that you are doing a "cleanup" with some renames then, could you please update the first comment to clarifies this PR? Note that, Add the subcommand concept to represent the actual operations returned by plugins. lead to belive it introduces a new design to the cli when you are doing renames mainly only. I mean, what means Add the subcommand concept? May something such as;

Description
// Add a summary of what was done here specifically. E.g

• Rename .. to ...
• add validation for ...

Motivation
// Why this change is required? What are the problems that are solved with it? User story usually is helpful as well to get the motivation.

shows that it mainly renames so I need to check it further now that the its motivation is clarified

[Adirio]

@camilamacedo86 Title, description and motivation updated.

[Adirio]

Ping @camilamacedo86 and @estroz

[estroz]

Looks good, just one nit about naming.

[camilamacedo86]

It shows great for me now either 👍
just address the @estroz nit #1748 (review) for we are able to get it merged

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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]

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

[estroz]

/lgtm