Hacker News Reader

Hacker News

Comment by harel | Hacker News Reader

Parent Full thread

harel

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

View on HN

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?

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.

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.

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 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.

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 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.

Reply on news.ycombinator.com