Readme claiming deprecated/non-existent functionality in CLI tool

[pykenny]

Readme file has a section showing that Cliche's CLI tool is able to run scripts that contain cliche.cli decorator usage, without running cliche install beforehand.

However, if one creates calculator.py and tries to run it as the screenshot does, then error message will appear instead of running the built CLI:

Usage: cliche [-h] [--cli] [--pdb] [--timing] {install,uninstall} ...

COMMANDS:
    install            Create CLI from current folder
    uninstall          Delete CLI

OPTIONS::
  -h, --help            show this help message and exit
  --cli                Outputs CLI and Python version info and exits.
  --pdb                Drop into pdb on error
  --timing             Add timings of cliche and function call
Argument command: invalid choice: 'calculator.py' (choose from 'install', 'uninstall')

From CLI's help document it seems that usage like cliche [script_file] [args] is not supported at this moment.

[kootenpv]

Yea sorry have not been updating this. Another interesting case I want to support is like a python package, which is already doable but not in the readme I guess.

I don't recall using cliche script_name.py in a long time so considered that support dropped.

Recommend:

• using install (it's nice)
• as python package (setup.py): example https://github.com/kootenpv/sysdm/blob/master/setup.py#L21
• add from cliche import main and add main() at the end of the script, and then call it like python my_script.py <args>

[pykenny]

I'm wrapping my scripts into a package, so now taking the second approach. Just wondering how to achieve hierarchical command lists with more than two layers (such as command_1 command_1_1 command_1_1_1 --some-option....) while it's possible to make it 2-layered by passing group name to cliche.cli decorator.

e.g. commnad_one.py

from cliche import cli

@cli('one')
def add(a: int, b: int)
  print(a + b)

@cli('one')
def sub(a: int, b: int)
  print(a - b)

__main__.py

from cliche import main

import my_package.cli.command_one

if __name__ == "__main__":
  main()

Now one add and one sub become available subcommands. But what if I want to create one another subcommand under one add (for instance, running something like one add print --color 10 20)?

[kootenpv]

There's only support for 2 levels which is plenty for 99% of command tools.

If you really wanted to you could create an enum as another level.. Just use it as a first argument and do different behavior based on the variant

But my personal experience when I thought 3 levels was good is that a 2 level refactor was better

[pykenny]

@kootenpv Support on deeply nested subcommands is emphasized in Typer's example, and DynaCLI claims to support the same feature with minimal modifications.

However, applications with super rich features (aka: complicated) as AWS's CLI usually have 2-layered subcommand structure at most, so I'm buying your argument 😬

[kootenpv]

Thanks for the references, much appreciated

I would need to see overwhelming "upvotes" to support 3 levels for me to consider it, otherwise not really an important feature to add