[chrismorgan]

I’ve worked with several of those ways of distributing Python apps over the years, mostly under Windows with a little under Linux and macOS, and mostly around a decade ago now, though I’ve touched a very little non-Windows stuff in the last year or two. They’ve consistently been more work than they seem even if all your stuff is pure Python, and there are just caveats left, right and centre. All kinds of stuff that should be fundamental and built-in was just extra effort at every step. Hooking up resources in the .exe file, controlling the Windows subsystem stuff, adding a manifest that works, figuring out which MSVCRT redistributables you need and how to hook them up (and you can’t pretty much just couldn’t automate this in any way), finding what library files (.dll, .so, whatever) you need because of dynamic linking, fixing library.zip stuff that just mysteriously didn’t work for some libraries, special-casing stuff here and there for C dependencies, tweaking optimisation and compression levels to try to speed things up and shrink them since startup is unreasonably slow and the distribution unreasonably large but these tweaks are also inconsistent and often break things, adding files your program depends on in a place where they’ll work, tweaking your code because it runs differently under py2exe or py2app or pyinstaller or whatever, trying to figure out why what you’ve built just isn’t even starting on so-and-so’s machine…

Granted, a few of these things apply to Rust stuff as well (e.g. resources and manifests can’t quite be done out of the box without extra tools), but most of them are inapplicable, and the remainder tend to have better solutions than I observed in Python-land. And a lot of the pain that I’m describing of the Python stuff isn’t that it’s hard to do anything, but more that I’ve found it all just exceptionally error prone and unreliable.