Hacker News Reader

Comment by bborud | Hacker News Reader

God, I wish people would stop using Python for these sorts of things.

It is an okay language, but after tracking down why it doesn't build and considering messing around in my system and making either installing older versions of libraries or messing around with symlinks I stopped and asked myself "really? I want to spend my time fixing this?" and just deleted the entire clone of the git repos.

Python is a nice language and all, but it is not a language suitable for writing applications that you distribute. (I wish the Python core developer would devote some time to making Python less horrible for distributing applications, but after around 30 years, I don't think so).

View on HN

- Click link, blown away by impossible feat of reverse engineering proprietary system done by apparently a lone hero contributor

- Realize nothing I work on really has so much impact as this one lone hero is likely to have already achieved by releasing this code

- Open HN thread with a sense of wonderment

- Read top comment, engulfed by a wave of revulsion, remember why we can't have nice things

My sentiments mirrored almost exactly.

Except to add that Python has issues but is clearly winning hearts and minds for a reason. It’s wonderful that an open source language has become so powerful, versatile, and widely adopted.

I’d take this era of computing over the days of ActiveX and Flash being the ubiquitous approach to releasing software.

I don't use Python, but I've never had any issues with any distributed Python app. I have, however, had endless problems with C and C++ apps.

The C way of referring to header files and libraries on the host system invariably leads to situations where the app wants to use a specific version that your system doesn't have. And we're not necessarily talking about system libs, either. Apparently authors thought the only way to mitigate the problem was to invent Automake/Autoconf in order to sniff what your system is capable of. (The saner solution for non-system libs would be to "vendor" your dependencies inside the app's source tree.)

Python has that pretty much solved with PIP. (Dependencies can still be a problem if a package uses the C way to link to things like Readline or OpenSSL or whatever.)

I deal with biology researchers trying to install various analysis programs. Python has caused me some pain recently. Its not easy, some use python 2.7 some packages use python 3.0. Many use different environments (pyenv/conda..). I ended up with a separate environment for each package..

To be fair java based software install isn't much better.

R is oddly a standout, in ease of installing packages. (Except the one time it didn't work, but in this case it wasn't much worse than anything else).

In general software distribution could be made much better.

Did you try to install OpenDrop?

Just hope you are lucky enough to have the right C dependencies installed.

I followed the instructions and it worked.

I honestly haven't run into this issue in a long time. `pip install --user` is one of your friends. Just using the official python:3 docker container is another. If you really want, you can even go back to virtualenvs.

npm was also really bad about nothing building or working a few years back. It's improved, and there are alternatives like yarn. Rust/Cargo has this issue as well (whenever I attempted to pick up some Rust; every example I found would break -- constant language changes were an issue; not sure if that's still the case).

Package management is a big problem in general, but we have solutions like the ones I've mentioned. This is a bad argument against not using Python. I honestly thing this type of application is fine in Python (you might need a privileged container if you go the docker route; wasn't sure how low level the Wi-Fi stuff it needs is).

What language do you recommend for this type of application and why?

Primarily any language that can produce executable binaries. Preferably statically linked binaries so that you can ship a unit that will not depend on the state of the system you try to run things on.

(With disk and memory sizes, dynamically linked binaries aren't really as relevant anymore since the often trivial cost of size more than makes up for the nontrivial cost of having to fiddle around to make things actually work)

Wasn't the original argument more about allowing the system to provide patches to shared libraries, therefore moving the burden of patching to sys admins instead of the developer of the package?

It's possible to produce a self-contained executable with Python, there's multiple solutions for this it's just not a part of the core language.

I agree that the situation isn't perfect in the python world but it's actively being worked on and I think PyOxidizer looks like one of the most interesting recent developments in this space: https://pyoxidizer.readthedocs.io/en/latest/

Some other alternatives (depending on your use case, e.g. target platform) are PyInstaller, py2exe, py2app, cx_Freeze, Shiv, PEX (basically tooling for native .pyz), XAR, Nuitka (compiles Python into a native binary), pyninst (creates windows installer), PEP 441 style .pyz (executable python archive, can easily vendor in dependencies). Then there's tools like fpm if you want to create packages for deb, rpm, FreeBSD, macOS .pkg, paceman, tar-archives, etc.

I've used some of these in enterprise settings building rich GUI-applications being distributed to end users who have no idea of what Python is and to whom underlying technology choices are invisible.

So with so many solutions to the same problem being made: which do you choose?

The thing is: for it to be useful people have to use it. And for people to use it nothing works better than one clear, idiomatic way.

If you have many solutions you often end up having no solution.

> What language do you recommend for this type of application and why?

This is the #1 reason why .NET Core gets so much of my mindshare these days. If I write something and put it out there, it will Just Work (TM) 99.99999% of the time. As soon as the user runs `dotnet build` or `dotnet run`, it'll automatically go grab the exact right versions of packages from NuGet and set everything up locally. The only time anything tricky ever happens is if some third-party library doesn't ship a native library dep for each platform; that's rare, but does occasionally happen.

Rust is pretty good about library support and reproducible builds

Gosh, I wish people stop complaining about the language choice whenever cool project X happens to be written in a pet peeve of theirs.

You’re right and the other half of this is the hoops you jump through as a developer to target as many python releases as possible. It’s insanity.

I built all of Cronitor in Python, still love it, but when we started building server agents it was not a hard decision to leave Python behind. (In this case, for Go)

I do agree that's an issue, although I wouldn't put it as drastic as you did.

I was working on a Flask project many years ago and it didn't seem straightforward to "vendor" dependencies with the `pip install` paradigm. Guess I was wrong.

https://medium.com/underdog-io-engineering/vendoring-python-...

There's a reason why virtualenv and similar exist. Another interesting point. Gentoo Linux (which uses Python in the Portage package manager) doesn't support installing modules as system (by default) to presumably avoid breaking the system package manager.

People use Anaconda to avoid this and get a pretty seamless experience. Lets you use multiple python configs on the same system and manages that for you.

I learned this when taking a computational finance class specifically to figure out why that and the quant/ai/ml community gravitated around python.

Python's advantages here came from about 12 years ago, when the syntax was friendly but other similar syntax friendly languages had a lot of overhead and other compromises. But these differentiators are mostly non-existent today, and Python is the only one with basically two different programming languages (py 2.x, py 3.x) operating under a single "Python" brand.

I agree, it really is to bad there isn't a better way of distributing Python. I've not had much of an issue with it running for console based pure linux stuff mind you, it tends to in my experience fall apart when you add gui elements and/or go outside of linux.

Does Python have something analogous to RVM or Gemsets, or Bundler (Bundler can exclude incompatible dependencies at runtime)?

Reply on news.ycombinator.com