This kind of "hey I will parse your CLI out of some callables' argspecs" has been done many times before:

- https://github.com/fritzo/parsable.py

- https://github.com/gissehel/cltools

- https://github.com/piranha/opster

- https://github.com/kennethreitz-archive/argue

- https://github.com/pdubroy/simpleopt

(all of those found from a 30 second GitHub search, so apologies if I've left one out or if one of those isn't exactly alike).

The thing is, the fact that you cut out some code does not make your thing more Pythonic, or simpler, or easier to use by itself. It's definitely a start, but CLIs are hard. And while argparse has its issues, if you try to supplant it, I don't doubt that you can get the simple cases right, but it's the more complex composition of components that is hard to do, and that's why I find anything in this realm hard to latch onto.

docopt is a nice step in a different direction, and I use it occasionally, but it's hard to do this -- for the simple cases argparse really isn't that bad, and I really really don't think that magically introspecting callables is a good approach. You will at some point want something more complicated, or to prevent some magic from doing somethings, and that kind of interface will become awkward, inextensible, and painful. Or at least that has been the case so far for anyone that's tried this.

So, applaud any code that anyone's sharing, apologies for coming down hard, but I don't think this is something anyone should use for anything but a trivial "hey here's my CLI it's a one off, and I don't want to learn argparse [which takes an hour or two]". And even for that, docopt is probably a better option.

I think the most popular is https://pypi.python.org/pypi/Baker/. And I like automatic introspection of callables very much - no more argument parsing, just a decorator under a function. Sure this is not suitable for polished CLI interfaces, but my use cases are almost only in-house scripts for internal usage.

+1 for Baker, it is the first script I import in my git repo when writing a python tool.

A big plus is that it is a single file (baker.py) with no dependencies, which is very useful when I have to use my scripts on machines I don't have root access on. (I know about virtualenv, but it is definitely overkill for most of the things I do)

Similar task solved in Java, though for interactive CLI. There it's much more needed, for we don't have argparse and the language's just too verbose.

https://code.google.com/p/cliche/

I'm working on one that distinguishes itself by attempting to be language-agnostic, meaning the subcommands are just executables, implemented in any language: https://github.com/datagrok/subcommander

It's not meant to replace argparse; it's meant to provide a namespace mechanism for a system with lots of sub-commands.

I've been using it at work for over a year. Needs some more polish and some bugs fixed before I'd call it "releasable" though.

Another project with similar goals: https://github.com/37signals/sub

I would suggest that you change the name -- manage.py is associated with django, I think... for most people in python land

Yes, definitely. People who google for "python manage.py" are looking for django-related stuff.

I prefer to use the batteries Python ships with; argparse is NOT that hard to understand. I haven't seen anyone that says otherwise who isn't just trying to pimp their side project.

...and?

You're in the wrong part of the Internet if "I made a tool that builds on something that already exists and is probably good enough for the smart person's needs" makes you shrug.

How does this compare to Fabric? Fabric offers a load of extra stuff to do with SSH/Deployment, but just looking at the basic features of running Python tasks from the command line, why should I use this over Fabric?

Also, why use `manager.arg` for documenting arguments, why not just use Python docstrings?

I was wondering the same thing. I also strongly associate manage.py with Django, so it confused me a bit when I first read it.

Fabric CLI syntax has been designed to chain commands.

Also thought about parsing args docstrings to get help and type, will be part of an upcoming release.

This seems to be for local manage scripts, like the one that comes with Django.

A couple years ago I wrote a similar library:

https://github.com/lucuma/pyceo

and I'm not the only one who feel argparse are optparse look very unpythonic (eg: http://flask-script.readthedocs.org/en/latest/).

My personal favorite is docopt: http://docopt.org/

Why this? https://github.com/Birdback/manage.py/blob/master/setup.py#L...

Would be more straight forward if you would remove that and let users just run python manage.py or ./manage.py

Then just add:

if __name__ == '__main__': manager.main()

to your manage.py

Human friendly and CLI - sounds little bit like a oxymoron.

Not when you consider which subset of humans the tool targets.

I wrote a little language with a similar goal a while back: https://github.com/pbiggar/buggery

argparse is pretty easy to use. I was able to build a git-like command line app with subcommands quite easily. Not sure why it needs a replacement.

You can do much of this with Fabric, specifying remote and local hosts. Cool piece of code though.