Seems neat, but to be honest, I had a really hard time reading the example because of all the encheferizer text. The funky, hard-to-read text is distracting me from understanding and appreciating the overall simplicity and elegance of things (in a kind of ironic way).
But, aside from that, I'm coveting this right now as I hack away with adding new options to my C++ program...
I was thinking the exact same thing. I had to read the text out loud in a European chef accent to understand what it was talking about. It really obfuscated the underlying meaning/simplicity of it for me.
You raise a fair point. The only reason I encheferized the readme example was to have a little fun with it, as one of its goals is to demonstrate help screens...but that ends up making the code look like a wall of text no matter what "language" the messages are in.
Anyway, once I think of a better example I'll swap it in. Thanks for your input!
I like it! Simplest use case it saves on boilerplate required by argparse. [1] But the potential for embedded apps is the real draw for me. I have a CLI app I'd like to provide a notebook GUI for... This would be perfect. Just swap out argparse for clip.py, write the embed script and the GUI can use the same methods. No need to code additional logic to handle GUI widgets.
I wonder how hard it would be to make my 'shkeleton' CLI parser embeddable -- it's basically argparse for bash scripting right now. [2]
shkeleton looks pretty neat too! Amazing that it's 100% bash, as someone who shies away from bash scripting for all but the simplest scripts I can't imagine recreating argparse in it :)
Well, my definition of "embeddable" is a very loose one. All you really need to be able to do is allow the user to specify in/out/err streams, so that they could be anything: a log file, a socket, a Python function, etc. So maybe keep a var for each of these and redirect the echos to them?
> For example, Click has integrations for fetching terminal dimensions and setting environment variables. This may be useful, but it also means trying to use Click for an embedded CLI (say, one running in a text editor communicating via websockets) is extremely difficult.
Why don't we have CLI programs with complex parseable options, something that could only be parsed by a parser generator, but would seem more natural to write, instead of lots of --flags --and --options.
> complex parseable options, something that could only be parsed by a parser generator
Could you elaborate on this? Do you mean user input more like natural language? I've seen a few attempts at this such as betty [1], but the reality of it is the input must still be translated into something the CLI understands, and as you might imagine it becomes difficult for more obscure options.
cornstalks|11 years ago
But, aside from that, I'm coveting this right now as I hack away with adding new options to my C++ program...
EpicDavi|11 years ago
willyg302|11 years ago
Anyway, once I think of a better example I'll swap it in. Thanks for your input!
joseph8th|11 years ago
I wonder how hard it would be to make my 'shkeleton' CLI parser embeddable -- it's basically argparse for bash scripting right now. [2]
[1] https://docs.python.org/2/howto/argparse.html
[2] https://github.com/joseph8th/shkeleton
willyg302|11 years ago
Well, my definition of "embeddable" is a very loose one. All you really need to be able to do is allow the user to specify in/out/err streams, so that they could be anything: a log file, a socket, a Python function, etc. So maybe keep a var for each of these and redirect the echos to them?
untitaker_|11 years ago
http://click.pocoo.org/
toyg|11 years ago
> For example, Click has integrations for fetching terminal dimensions and setting environment variables. This may be useful, but it also means trying to use Click for an embedded CLI (say, one running in a text editor communicating via websockets) is extremely difficult.
EpicDavi|11 years ago
1. https://github.com/willyg302/clip.py/blob/master/docs/main.m...
fiatjaf|11 years ago
Just thinking about it.
willyg302|11 years ago
Could you elaborate on this? Do you mean user input more like natural language? I've seen a few attempts at this such as betty [1], but the reality of it is the input must still be translated into something the CLI understands, and as you might imagine it becomes difficult for more obscure options.
1. https://github.com/pickhardt/betty