31–40 of 64 posts
The thing that bugs me about click is that now your python script has a python dependency that you have to install every time you need to run the script. This is fine sometimes, but a lot of the time I want a script that will be usable with minimal setup, which is why I always use argparse, which is in the standard library, and gets the job done despite its quirky API.
Earlier quoted context omitted.
This is more of a packaging problem. There are various ways to package python code with it's dependencies into a single executable. In any case, comparing a stdlib library to a 3rd party one is a bit apples to oranges. Most people first decide whether or not they want to use pypi packages, and then start evaluating which ones are appropriate.
> Most people first decide whether or not they want to use pypi packages, and then start evaluating which ones are appropriate. I don't think it's as binary as this. There should be, at least intuitively, a mild negative bias to adding a marginal dependency, even once you're dependent on pypi. We're lucky enough to not be dealing with a dumpster fire ecosystem like nodejs, but it's still a good habit. For me, writing…
Earlier quoted context omitted.
sure, if you're building a CLI to do management commands for an application that already has dependency management in place, that's all fine but if you just have some basic script to scrape some logs or zip up files, its nice to have it be self contained
if it's a simple basic script, i wouldn't even go through the pain of using argparse. i would just manually check sys.argv.
My favorite library for this is docopt[0], which parses the docstring at the top of your script. It’s a lot easier for people reading your code to see the usage up front rather than scrolling to the bottom and finding your main() and reading the argparse calls: #!/usr/bin/env python3 “”” Usage: ./myscript.py [ ] “”” from docopt import docopt if __name__ == ‘__main__’: args = docopt(__doc__) print(args[‘ ’], args[‘ ’]…
Earlier quoted context omitted.
> Most people first decide whether or not they want to use pypi packages, and then start evaluating which ones are appropriate. I don't think it's as binary as this. There should be, at least intuitively, a mild negative bias to adding a marginal dependency, even once you're dependent on pypi. We're lucky enough to not be dealing with a dumpster fire ecosystem like nodejs, but it's still a good habit. For me, writing…
Click is multiple order of magnitude better than argparse. I don't even start a CLI app with argparse anymore, because even with very simple interfaces you will hit it's limitations. You should try click.
i'm sorry but this is not how decorators are supposed to be used. I also doubt that click does decorators correctly too. I couldn't get them working on a instance method for example. Just stick to the standard library on this. A dependency is not worth it here.
Earlier quoted context omitted.
sure, if you're building a CLI to do management commands for an application that already has dependency management in place, that's all fine but if you just have some basic script to scrape some logs or zip up files, its nice to have it be self contained
Perhaps a non-starter for you if you don't want to involve Docker but I have had good experiences wrapping a docker invocation in a shell script shim with the same name as the program and forwarding everything I need into the container. Then folks just grab the shell script and they're off... added bonus it's really easy to add update functionality to your tools.
I'm not sure why click is often recommended. I've used argh for years and find it easier: def hello(name): return "hello {}".format(name) def ping(): return "pong" if __name__ == "__main__": import argh parser = argh.ArghParser() parser.add_commands([hello, ping]) parser.dispatch()