Allow for a default subcommand

[rodr0m4]

First and foremost:

• My english sucks
• This library is amazing! (I was looking for a way to quickly make CLIs with interactive + non-interactive mode without repeating logic and this was exactly what I was looking for :) ).

Given something like this:

@command
class Token:
  @command
  def provider_a():
    get_token_for_provider_a()

  @command
  def provider_b():
    get_token_for_provider_b()

I'd like to provide a default subcommand to call when no arguments are passed, so I could call that command like:

> cli token

And behind the scenes token.provider_b() would be called, for example.

This is because doing something like cli token --provider=b is kinda verbose (at least for my use case).

Does this make sense? Or I'm trying to use subcommands for something that they are not intended for?

[AhmedSoliman]

This is currently not supported but I don't think it's going to be hard to support. Do you like to take a stab into extending Nubia and supporting it?

However, it's possible to do what you want now manually by doing something around:

class Token:
  def provider_a():
    get_token_for_provider_a()

  def provider_b():
    get_token_for_provider_b()

MAPPING = {"a": Token.provider_a, "b": Token.provider_b}

@command
@argument("provider", choices=["a", "b"])
def token(provider: str):
    t = Token()
    return MAPPING[provider](t)

[rodr0m4]

I'd like to do so 😄.

I thought about four ways of solving this:

• Add a default parameter to @command, which would make Nubia call that subcommand when no argument is given (kinda ugly, only works on subcommands because interactive mode)
• Add a @default decorator, usable in subcommands (Would enlarge the API surface without that much gain I think).
• Make it possible to use @argument in supercommands, and add a default property to it (only useful in the context of subcommands, because in every other case we have default arguments).
• Have a magic method default_subcommand in supercommands that will be called when no subcommand is given.

What do you think @AhmedSoliman?

[AhmedSoliman]

On one hand, I like to see which command will be the default right on top where the class definition starts (by decorating the class itself). But that probably means that we will write the sub-command by name (string) which can break easily on refactoring.

On the other hand, annotating the command itself makes will remove this requirement. But it's easy to see multiple commands with that decorator by mistake and will be hard to know which one is default quickly if a file is too big.

I'm leaning more towards annotating/decorating the class itself with @super_command that is optional by design but can be used to customise super-command-specific options like default. What do you think?