Hacker News Reader

Hacker News

Comment by thunkshift1 | Hacker News Reader

Parent Full thread

thunkshift1

Why is python bad for cli applications

View on HN

Packaging and deploying Python apps is an adventure.

If you don't know how to do something, everything is an adventure.

Your comment really isn't adding any value to understanding the state of Python packaging.

From my personal experience, there's so many things that can crop up, not limited to:

- Conflicts with system packages from e.g. apt

- Conflicts with system packages from easy_install/pip

- Mismatching Python versions (even among 3.x with syntax additions only available in newer versions)

- Different dependency management systems (pip's requirements.txt, setuptools's setup.py, poetry's pyproject.toml, etc.)

- ... and the list goes on if you start talking about C extensions!

Additionally, not everyone does things in the same way which means the easiest way to package Python tools tends to be just bundling Python + its entire standard library together. Contrast this with Go, where `go install` does basically the right thing 9 times out of 10. I'm not a huge Go fan, but the convenience of `go install` is really unmatched.

In my experience, `pipx install` (with `--system-site-packages` if you want system Qt themes) generally works as a user, though it breaks when the Python version updates, it doesn't generate a zero-dependency easily-deployed binary, and the packaging ecosystem is indeed a serious problem as a developer. Have you experienced other issues using it?

virtual environments address all these concerns, no?

Absolutely not. A virtualenv is typically a pointer to a systemwide python, or something managed by yet another piece of crap - chpy, asdf, whatever - they are not self contained. Upgrading the system python will typically break the virtualenv.

Anything, even a statically linked binary can run into problems if you upgrade the entire OS..

Not really on linux.

I mean if you upgrade from x11 to wazland and zour app depends on x11 then sure, but I still use binaries that were compiled in 90s (some because I dont have the source)

And windows is also very backwards compatible.

I mentioned this on another reply, but Windows has as far as I remember a way to wrap a Python program as an exe executable. Maybe it's time for python to have a universal go-like binary. Yes, a 1KB program will turn into a 300MB behemoth, but people don't seem to mind it with Electron (I don't usually) so maybe it can work.

I think “adventure” implies significant depth into the unknown which one must traverse. A single coin flip is also an unknown but generally wouldn’t be described as an adventure.

Years ago I went on a long distance canoe trip in the Arctic. It rained every day, the mosquitos ate us alive, and I came uncomfortably close to hypothermia. It was a great experience and an adventure - that's what I was thinking of.

Doing the same for a Go CLI or an Electron app is a walk in the park. I did it in minutes from not knowing anything and it worked on people's computers. I'd choose it any day.

I have successfully used CPAN, Maven, NuGet, Homebrew, and other packaging systems while knowing little about them. You can copy a snippet, install the package, and get back to work. Why should Python be any different?

I agree. I've used Python for a decade. Go and Node are a pain in the ass compared to Python, simply because I am unfamiliar with them. Use tox to create a virtualenv and then you can run irrespective of system packages and build the virtualenv in a single 'tox' command.

you should try PyInstaller

If you are good, you don't have to worry about it. I never have to, because my scripts use packages easily available from pip and I keep them up to date as things change.

Right from the very first bytes of your cli app you run into issues. The interpreter line. You have to choose #!/usr/bin/python or #!/usr/bin/python2 or #!/usr/bin/python3 (or similar variations with /usr/bin/env). All of these happily ignored by Windows. The latter two may not exist on some platforms. The first one could be invoking either a python2 or python3 interpreter.

There's some python magic for determining the version, but if you use a feature not supported by the version it raises an uncatchable exception...because python's parser has control before your code has control.

This isn't the only deployment issue, but a good example of what you're in for.

I_like_ writing CLI apps in Python, and for various reasons haven't been subjected to the packaging woes, but I think execution latency is an important thing for CLI tools, and I've had enough Python CLI tools spend most of their time (a user-perceptible amount) loading modules that I prefer less dynamic languages for tools that aren't completely trivial.

Could you write a guide? Pretty please? I've had nothing but woe in this realm, and anytime one asks about this the answers usually contradict each other, or leave out significant detail. I think an article that details your workflow could be tremendously interesting for others.

What problems do you have with CLI apps? In my experience, the problem is whether you're targeting developers (i.e., people that can run pip install <tool>) or end-users (those that just want to run a binary).

Python is hell for the latter. I support Windows and Linux, so I can bend pyinstaller to my will with enough effort, but I need to have a special Windows VM to "cross-compile".

For the former, though, it's a matter of creating a setup.py and telling the user to pip install the repo on GitHub. Or you can use Poetry, which makes things slightly easier.

It makes sense that _you_ as an author don’t think of python packaging as a problem - it’s only really inflicted upon non-developer end users of the products.

Oh, I'm sure it's a problem; the reason I haven't been subjected to these problems is because I mostly deploy tools to an environment that has pre-existing build system and deployment solutions for this that I don't have to maintain.

Reply on news.ycombinator.com