top | item 38585403

(no title)

_dmn7 | 2 years ago

As a developer for a Python GUI application [1], I think the biggest problem with using Python for desktop applications is the packaging. All existing tooling for creating a distributable binary either stops working or starts to require nontrivial hacks once you have more than a few dependencies. Even popular packages have issues. You get cryptic missing hidden import problems and missing data files that you didn't know were ever needed. Some dynamic module loading also stops working once they are brought outside of the normal python environment, which is the case if you use PyInstaller or cx_freeze. I'm not sure what can really be done here. Maybe Python needs to propose a standardized way to package standalone programs like Java's jars that only depends on the interpreter.

1. https://github.com/FreeLanguageTools/vocabsieve

discuss

order

networked|2 years ago

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|2 years ago

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.