Disclaimer: I'm not arguing for or against having pyinstaller or the like in the stdlib. Probably slightly against. Anyway...
On 19Nov2020 15:59, Chris Angelico email@example.com wrote:
Producing native executables is an attractive nuisance. [...stuff...]
To me, the beauty of things like pyinstaller is that they produce a _complete_ package/bundle/executable which you can just use. More to the point, that you can hand to someone else to use.
I've been using py2app to build a Python+PyQt app for a Mac for a client. It makes a working MacOS .app that contains your dependencies (python itself, various libraries), and on MacOS an app is a complete package -- it contains a bin directory and the associated assets (libraries, static assets like images, what have you).
There's a standard layout and the MacOS runtime linker has cool hooks to let you specify library paths _relative_ to the executable. Which means you can plonk the .app down anywhere and it just works.
Getting that right yourself is _hard_. Well, I found it hard to debug when there were problems.
In particular, the "find all the dependences and bundle them so that they still work" is hard.
A tool which "builds an app" is very very useful - you can hand your client something whose install is "copy it here" (on a Mac, usually /Applications). And they're golden.
Anyway, this is a long winded way of saying that your misgivings about executables (fixed source code and/or python version) are often a fair price to pay to "just give it to someone" and have it work. If it needs an update or bugfix I can just give them a newer one.
BTW, py2app also has a "dev mode", a bit like pip's -e option, to use the "live" source tree instead of a fixed bundled source.
Cheers, Cameron Simpson firstname.lastname@example.org