I’ve noticed that I never quite feel at ease with the Python programs I write.<p>I’ve been using Go to create projects, both big and small, since 2013.<p>Almost every time I attempt to build something even remotely complex with Python, I end up regretting it, especially when other people besides myself start using these programs. The main problem is the lack of assurance that the same program will function correctly on another person’s computer. With Go programs, it’s as simple as having a statically linked binary, and given the ease of cross-compilation, I’m very confident that what works on my machine will work on my coworker's or customer's computer as well.<p>You know how some people suggest that Shell scripts should not exceed a certain number of lines, because beyond that point, it’s better to create a Python, Ruby, PHP, or similar script? I experience a similar sentiment when working with Python. A few hundred lines may be acceptable, but anything larger than that, I believe, is better suited to be written in a compiled language.
I build little CLI tools in Python non-stop. ChatGPT and some basic knowledge of how the `click` library works has made it almost completely trivial to get the ball rolling for whatever need I have for it, `--help` text included.<p>The fact that the barrier for creation is so low means I'm even willing to do them to solve very niche problems in generalizable ways. [1] is common enough that a few people have starred it. [2] is niche enough that other Anki folks haven't used it AFAICT. [3] is likely something I'll never personally need again, even though Azure VM reservations not letting you customize your reminders for when they're about to expire is probably a costly mistake for a great many firms.<p>All started with this same starting methodology, because what I wanted was <i>just</i> a little too fiddly to want to hack together with my shell toolkit.<p>[1]: <a href="https://github.com/hiAndrewQuinn/finstem">https://github.com/hiAndrewQuinn/finstem</a><p>[2]: <a href="https://github.com/hiAndrewQuinn/table2anki">https://github.com/hiAndrewQuinn/table2anki</a><p>[3]: <a href="https://github.com/hiAndrewQuinn/AzureReservations2ICS">https://github.com/hiAndrewQuinn/AzureReservations2ICS</a>
I'm sure click has its advantage if your CLI is particularly complex, but for me the built-in argparse is more than enough, it has almost all the common things you need.<p>By the way, argparse (and I assume click too) by default allows having positional arguments and switches in any order, i.e., both:<p><pre><code> mycli pospara0 --switch --option A
mycli --switch --option A pospara0
</code></pre>
work. This seems like nothing but I've encountered many CLI utilities written in other languages (particularly, go and node.js) that force you to have switches at the beginning. and I <i>really</i> hate that.<p>I don't know if it's caused by their corresponding default/popular CLI library or what, someone could enlighten me.<p>(Of course, in some cases like things like FFMPEG, the order absolutely matters; but it's not the case for 99% of utilities.)
I have been using Typer on every one of my CLI projects which uses Click under the hood. The documentation is fantastic, the CLI app it produces looks great and Typer lets you create things quickly. I high recommend it.<p><a href="https://typer.tiangolo.com/" rel="nofollow noreferrer">https://typer.tiangolo.com/</a>
I've been using docopt to handle CLI arguments for years now.<p><a href="http://docopt.org/" rel="nofollow noreferrer">http://docopt.org/</a>
>> Flags with single character shortcuts can be easily combined—symbex -in fetch_data is short for symbex --imports --no-file fetch_data for example.<p>I pretty much use argparse for making all my CLI tools, but I dont know of an easy way of doing this single character flag thing. Is it possible/easy with argparse?
In my experience building large applications in Python becomes delicate due to the lack of static typing, as well as overlooking issues of scope in variable usage. It can be avoided with diligence but I’ve definitely shot myself in the foot and let errors slip through in Python programs I’ve written for the above reasons, which ended up compromising the validity of the program (mainly automated test scripts that were used to test other software and hardware).<p>I’ve only been programming for about 5 years in earnest. I held on to Python for dear life in the first days of my career, but have since transitioned to full-time C/C++ development, primarily in embedded and hardware interfacing applications. I feel like my large programs are much more manageable and maintainable now. Some of this is of course due to having grown as a programmer as well.
The folks at Textualize have taken it one step further with <a href="https://github.com/Textualize/trogon">https://github.com/Textualize/trogon</a><p>It's a neat way to make powerful CLIs more accessible to less-technical users.
I've came to the same conclusion as the author some time ago, my cookiecutter template is more opinionated <a href="https://github.com/ArcHound/python_script_cc">https://github.com/ArcHound/python_script_cc</a> . Best for use-cases when you need to do some automated API calls. Will checkout Typer and Textualize too, thanks HN!
Is there a way to compile a python CLI script, and it’s dependencies and python itself into an executable.<p>That makes the tool nicer to use. To me a CLI tool should stand alone ideally. Obviously that is not the trend as many things that are CLI are installed via node or npm.<p>I guess docker could solve most of the issues here
I’ve used Tyler and Fire and like them both but recently I’ve been in search for a Python Lib that gives user numerical choices and allows arrow navigation, like the “gh” (GitHub) CLI. I wasn’t able to find one. Anyone has a rec? Thanks
Saw "Click" being used. Didn't read further. This is worthless.<p>For those who don't know. Python has argsparse package that ships with every Python distribution. It's much better in terms of organizing command-line arguments, easier to debug, easier to extend (which is very rarely necessary).<p>Click is a third-party dependency. It's not solving any real problems. It's not like argsparse had a problem and Click came to solve those. It's just that author had too much spare time on their hands and decided to learn how to do something new. The author made some rooky mistakes along the way. He totally misunderstood how locales and encodings work and for a while Click was a source of errors related to that. Maybe still is, but fewer packages are using it? -- I don't know.<p>If anyone chooses to use Click over argsparse, it only means lack of research. Following fads w/o any sort of independent thinking. Not someone I'd encourage to take advice from.