Commit 4981f597 authored by ∞'s avatar 💻

Update README

parent b7ffddf2
Pipeline #1796 failed with stages
in 16 seconds
......@@ -6,7 +6,9 @@ qa:
pytest:
stage: test
image: yourlabs/python
script: pip install -e . && py.test --cov . -v
script:
- pip install -e .
- py.test --cov . -v
pypi:
stage: deploy
......
README FROM FIFTH REWRITE THAT is in old_cli2.py and old_test_cli2p.py
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another choice to click and docopts, here lies the docs for old_*.py that was
the fifth version (fourth rewrite) of the cli extracted from another product
in development (playlabs, deployment for lone wolves).
Install cli2 ie.::
$ pip3 install --user cli2
Cli2 can be used as a generic command line to execute callbacks and print
docstrings::
$ cli2 --debug your.callback
$ cli2 your.callback arg0 kwarg0=aoeu
, or as a CLI framework: first give it a name in the
``console_scripts`` entry point like ``yourapp`` and point it to
``cli2:console_script``, example using `setupmeta
<https://github.com/zsimic/setupmeta>`_'s ``entry_points.ini``::
[console_scripts]
yourapp = cli2:console_script
Then register your commands easily, ie::
[yourapp]
# bind yourapp help to cli2.help
yourapp help = cli2.help
# bind yourapp run to yourapp.cli.run
yourapp run = yourapp.cli.run
# bind yourapp * to callbacks in yourapp.cli
yourapp * = yourapp.cli
Help::
Clitoo makes your python callbacks work on CLI too !
This CLI can execute python callbacks with parameters.
Clitoo recognizes 4 types of command line arguments:
- lone arguments are passed as args
- arguments with = are passed as kwargs
- dashed arguments like -f arrive in context.args
- dashed arguments like -foo=bar arrive in context.kwargs
It doesn't matter how many dashes you put in the front, they are all
removed.
To use the context in your callback just import the clitoo context::
from clitoo import context
print(context.args, context.kwargs)
Clitoo provides 2 builtin commands: help and debug. Any other first
argument will be considered as the dotted path to the callback to import
and execute.
Examples:
clitoo help your.mod.funcname
Print out the function docstring.
clitoo debug your.func -a --b --something='to see' how it=parses
Dry run of your.mod with arguments, dump out actual calls.
clitoo your.mod.funcname with your=args
Call your.mod.funcname('with', your='args').
Demo::
$ clitoo debug your.func -a --b --something='to see' how it=parses
Could not import your.func nor clitoo.your.func
Args: ('how',)
Kwargs: {'it': 'parses'}
Context args: ['a', 'b']
Context kwargs: {'something': 'to see'}
Fallbacks
~~~~~~~~~
Clitoo will attempt to fallback on packages of its own. If it doesn't find the
`git.clone` callback from the `git` package, or doesn't find the `git` package
itself, it will find `clitoo.git.clone` which is a builtin command that we use
in CI.
Making your own command
~~~~~~~~~~~~~~~~~~~~~~~
See the djcli repository for an example of command that is packaged as
standalone, but it looks like::
# Declare the following as CLI entry_point
def cli():
clitoo.context.default_module = __name__
return clitoo.main()
cli2: unfrustrating python CLI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes I just want to execute a python callback and pass args/kwargs on the
CLI, and not have to define any custom CLI entry point of any sort, nor change
any code, typically when automating stuff, cli2 unfrustrates me::
cli2 yourmodule.yourcallback somearg somekwarg=foo
Sometimes I just want to define a new command and expose all callables in a
module and I can't just do it with a one-liner. cli2 unfrustrates me::
console_script = cli2.ConsoleScript(__doc__).add_module('mymodule')
I also like when readonly commands are in green, writing commands in yellow and
destructive commands in red, I find the commands list in the help output more
readable, and directive for new users of the CLI::
@cli2.config(color=cli2.RED)
def challenge(dir):
'''The challenge command dares you to run it.'''
os.exec('rm -rf ' + dir)
Of course then there's all this code I need to have coverage for and I'm
`still
<https://pypi.org/project/django-dbdiff/>`_ so lazy that I still
`don't write most of my test code myself
<https://pypi.org/project/django-responsediff/>`_, so I throwed an autotest
function in cli2 that I can use as such::
@pytest.mark.parametrize('name,command', [
('cli2', ''),
('help', 'help'),
('help_debug', 'help debug'),
# ... bunch of other commands
('debug', 'debug cli2.run to see=how -it --parses=me'),
])
def test_cli2(name, command):
cli2.autotest(
f'tests/{name}.txt',
'cli2 ' + command,
)
This will execute the command and compare with the contents in the test text
file with GNU or busybox diff and fail if there's a diff. If the file doesn't
exist then it will create it and fail because it created the fixture. I can
just rm -rf my tests dir and run pytest again, and use git diff to see what
has changed.
You should be able tho pip install cli2 and start using the cli2 command, or
cli2.ConsoleScript to make your own commands.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment