[djsumdog]

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?

[bborud]

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)

[packetlost]

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?

[hultner]

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.

[bborud]

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.

[daeken]

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

[derrick_jensen]

Rust is pretty good about library support and reproducible builds