Make Groups public field for command

[andig]

Fix #1831.

This PR is a BC break as it replaces Groups() with the Groups field. This could be fixed by keeping CommandGroups as public member name but felt clearer not duplicating the api.

[CLAassistant]

All committers have signed the CLA.

[marckhouzam]

Thanks @andig .
With Cobra we cannot break backwards-compatibility. It is crucial that a project continue to compile after upgrading to a new release of Cobra. Could you update the PR to retain backwards-compatibility?

Also could you describe how users would make use of this change to improve the use of groups?

[andig]

@marckhouzam the feature has only been introduced 9 days ago and like does not have wide-spread use. It also encourages a close coupling. Happy to rework, but it seems better to make this change cleanly and quickly.

[marckhouzam]

@marckhouzam the feature has only been introduced 9 days ago and like does not have wide-spread use. It also encourages a close coupling. Happy to rework, but it seems better to make this change cleanly and quickly.

I'll let @jpmcb disagree, but in my opinion, once it is out, that's it, projects can be using it. That is why I was so detailed on getting as good an API as we could from the start.

[jpmcb]

I'm not seeing how this is a breaking change?

Looks like we want to add the commandGroups as part of the public API and since it wasn't to begin with, I don't believe adding it will break anyone's programs?

I'm also not seeing how this solves #1831. Can you provide an example using this newly exposed API from this patch to give an explanation / example?

[andig]

I'm not seeing how this is a breaking change?

@jpmcb 7aa995f is a breaking change (Groups() -> Groups). cd90af1 isn't and will have both Groups() and CommandGroups.

I'm also not seeing how this solves #1831.

The problem with #1831 is that the root commands groups must be created have ben added for the sub command to use them. Typically root command is created groups are added during init() which runs after subcommand is declared and hence panics. This PR fixes that by adding groups to the root command variable at creation time instead of during init():

var rootCmd = &cobra.Command{
  Groups: []*cobra.Group{&cobraGroup{...}}
}

Imho the current Groups api is not quite fit for purpose- or I'm missing a better approach to use it.

Typically root command is created groups are added during init() which runs after subcommand is declared and hence panics.

Update even moving sub command declaration to it's init function won't fix that as it will run after root command's init().

[andig]

I'll let @jpmcb disagree, but in my opinion, once it is out, that's it, projects can be using it. That is why I was so detailed on getting as good an API as we could from the start.

@marckhouzam I do by no means want to imply you did a bad job. Hope it doesn't come across like that. I may really be missing something! Just didn't find a good approach that fits (my) current pattern of using cobra commands.

[marckhouzam]

I'll let @jpmcb disagree, but in my opinion, once it is out, that's it, projects can be using it. That is why I was so detailed on getting as good an API as we could from the start.

@marckhouzam I do by no means want to imply you did a bad job. Hope it doesn't come across like that.

Not at all! I was just explaining why we were so demanding with the original review. Once an API is published we can never break it 😅

And thanks for continuing to improve this feature. Clearly people want it as we already see multiple users 👍

[marckhouzam]

I'd like to think a bit about this init() ordering issue.
And we'll need to document the final way we settle on so the users know exactly how to create groups safely.

[marckhouzam]

Let's look at the basics of the situation.
Our current API is:

1. Call AddGroup()
2. Call AddCommand()

These calls must be in the above order because (and only because) we verify if all groups properly exist when calling AddCommand().

The problem is that when using inti() functions, users don't have a good control of the above order.

Notice that if we don't verify the correct existence of groups, then the ordering does not matter and everything will work.
So, we could simply remove the check and the panic from AddCommand().

But as discussed in the original PR, it would become easy for a typo in a group id to go unnoticed which would make the subcommand with the wrong id not to be shown in the help.

So instead of completely removing the check, how about we move it to a point where the order of initialization no longer matters? I believe we can do that by adding the check in ExecuteC(), once the help and completion commands have been created.

What do you think?

[andig]

What do you think?

I had actually thought about that but kinda forgot. Sounds very good- validate existence of all group/IDs without depending on order.

[jpmcb]

So instead of completely removing the check, how about we move it to a point where the order of initialization no longer matters?

I think that's a very solid solution here: Let's not re-work the API, let's decouple it so calls don't depend on ordering.

[andig]

@marckhouzam would you be so kind to provide the follow-up PR? I'm unsure where to put the validation now.

[marckhouzam]

@marckhouzam would you be so kind to provide the follow-up PR? I'm unsure where to put the validation now.

I've created #1839. If this solution looks good, we can close the current PR.