Live data from Hacker News

Click – Python library for command-line interfaces

click.pocoo.org

101–105 of 105 posts

Re: Click – Python library for command-line interfaces

#102

I should write up a comparison between: - Cement ( http://builtoncement.com ) - Cliff ( http://cliff.readthedocs.org/en/latest/ ) - Plumbum ( http://plumbum.readthedocs.org ) - Argh ( https://pypi.python.org/pypi/argh/0.24.1 ) - Aaargh ( https://github.com/wbolster/aaargh ) - Baker ( https://pypi.python.org/pypi/Baker/ ) So many more to choose from. Now we get to evaluate Click. Seems like the reason Armin wrote Clic…

cliapp ( http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cliapp/ )

Re: Click – Python library for command-line interfaces

#103
post #79

Earlier quoted context omitted.

Armin, my feedback is in the form of my own version of this library.[1] I have been working on this on and off for some time and like you have not made a release. That said, I have been using it quite a bit both in my research and at work and I think it helps. The main idea behind it is make it easy to write a "getopt" style program with arbitrary command nesting. I have found that although argparse and sisters are n…

> I have found that although argparse and sisters are nice libraries they don't allow me to do many of things I like to do in my interfaces. For instance sometimes like options such as ? This is trivial to do with argparse (or optparse for that matter): import argparse def a_prefixed(string): if not string.startswith('a'): raise argparse.ArgumentTypeError("%r does not start with 'a'" % string) return string parser =…

@masklinn good point. I haven't used argparse (mostly out of compatibility requirements with 2.6). So I may have mis-characterized the state of the art. It does do many things well. One note, is that the `prefix parsing` functionality could cause weird behavior when doing partial parsing (which I do a lot of).

> Isn't that what the callback parameter is for, especially with is_eager=True? Or ParamType if you need either something more reusable or something more extensive.

yes. I think almost everything should work like this. I think the getopt style makes this a bit easier to understand.

> http://click.pocoo.org/api/#click.File, argparse has something similar.

Not at all the same. I never said my programs were going to open the files themselves. I often have to write automation scripts around other things. In these cases I need to make sure files and directories are sane but I don't open them. I just canonicalize them and pass them on.

The big thing is the lack of integration with configuration files which is something I am still working on myself.

Re: Click – Python library for command-line interfaces

#104
post #57

Earlier quoted context omitted.

Yeah, plenty: - Cliff http://cliff.readthedocs.org/en/latest/ - docopt http://docopt.org - argparse - optparse etc etc etc...

There's also Clint by Kenneth Reitz ( https://github.com/kennethreitz/clint )

Clint is a cmd tool not parsing tool

Re: Click – Python library for command-line interfaces

#105

I should write up a comparison between: - Cement ( http://builtoncement.com ) - Cliff ( http://cliff.readthedocs.org/en/latest/ ) - Plumbum ( http://plumbum.readthedocs.org ) - Argh ( https://pypi.python.org/pypi/argh/0.24.1 ) - Aaargh ( https://github.com/wbolster/aaargh ) - Baker ( https://pypi.python.org/pypi/Baker/ ) So many more to choose from. Now we get to evaluate Click. Seems like the reason Armin wrote Clic…

https://pythonhosted.org/pyCLI/#
Post reply on HN