[networked]

Python has zipapps (https://peps.python.org/pep-0441/), which are standardized and similar to JARs. You can build a zipapp that includes your application's dependencies using a tool like shiv or PEX, only with binary extensions the artifacts are still per-platform: https://github.com/linkedin/shiv#gotchas.

I recommend users to install my Python programs with pipx (https://github.com/pypa/pipx). I think it is the best option when the audience is at all technical. pipx makes such a big difference for managing Python applications. It avoids the version conflicts of `pip install --user` and the pain of manually creating per-application venvs. In general, it provides a reasonable user experience. Because of this user-friendliness, I can recommend pipx as the primary installation method and expect people to succeed at installing the program with it. (I don't see issues about pipx installation in the trackers of projects that recommend it.) My programs have binary dependencies but no GUI.

[raffraffraff]

Pipx still breaks. I tried to use something a few days ago that had been working until a month ago and it failed with some useless generic python error that I can't remember. I looked at the code in the /usr/bin/thing and it was just a wrapper. After following the rabbit around I just uninstall pipx, install it again, and then reinstall the thing that I was originally trying to use. No idea what broke it, perhaps a python update or something. The 'dead' version is probably still hanging around in my home directory taking up space somewhere.

Python absolutely sucks in this regard and I don't think there is a permanent solution. Except give python a compiler that can spit out binaries and libraries. I wish nim was 100% python code compatible.

Compiled binaries with shared libs work fine as long as they come from an OS package repository. Statically compiled binaries work almost everywhere. But a script that needs a bag of other specifically versioned scripts needs to live in it's own (sometimes impossible) world. Hell, I've even had a single pip install on a clean system fail because two dependencies of the module I was installing wanted different versions of some common dependency. Gah, burn it with fire.

I'm always amazed at the Windows ecosystem. I can download something that was built in the 90s and happily run it in wine.

[networked]

Yeah, I've had pipx break once with a generic error. It was after a Python version upgrade. I also ended up reinstalling pipx and the applications to fix it. I should qualify my recommendation. With pipx, your application will very likely install and work correctly, but it won't necessarily stay working when the Python installation changes. A self-contained binary is better in this way.

I don't see Python packaging and dependency management as a bulldoze-everything-and-start-over disaster anymore. Thanks to improvements like wheels, manylinux, `pyproject.toml`, https://peps.python.org/pep-0517/, and Poetry/PDM/Flit/Hatch/etc. they are increasingly adequate.

I have compiled a Python application to a native binary with https://github.com/Nuitka/Nuitka. Once I got it to compile, it fully worked. The process was a little fiddly, although I don't remember the exact problem. In the end I set up a Docker container for the build, and then it built. Maybe Mojo will be what you wish Nim was.

For standalone scripts, there are options. (My list: https://github.com/stars/dbohdan/lists/python-scripts-with-d....) Support for scripts should be coming to pipx. I have used the development version and liked it. This is an area where things are actually pretty good but not common knowledge.

> I'm always amazed at the Windows ecosystem. I can download something that was built in the 90s and happily run it in wine.

https://blog.hiler.eu/win32-the-only-stable-abi/ :-)