PyOxidizer

You are correct. I just hadn't noticed: - Project Status Update: https://github.com/indygreg/PyOxidizer/discussions/740 - https://gregoryszorc.com/blog/2024/03/17/my-shifting-open-so...

> Many users of these distributions might be better served by the PyOxy sister project [1]. PyOxy takes these Python distributions and adds some Rust code for enhancing the functionality of the Python interpreter. The official PyOxy release binaries are single file executables providing a full-featured Python interpreter. 1: https://github.com/indygreg/PyOxidizer/ From that readme, it seems PyOxy has a few related uses: - It can produce a single file executable representing a Python app including the interpreter - It can ship self-contained Python interpreters and related to be embedded or used as a library in a larger application - PyOxidizer can serve as a bridge between Rust and Python - "PyOxidizer can be used to easily add a Python interpreter to any Rust project. But the opposite is also true: PyOxidizer can also be used to add Rus

> Strange this with this whole incident apart from the rewrite/LLM part is the general misundrstanding of the licences. LGPL being a pretty permissive one going as far as allowing one to incorporate it in propriety code without the linking reciprocity clause The short version is that chardet is a dependency of requests which is very popular, and you cannot distribute PyInstaller/PyOxidizer builds with chardet due to how these systems bundle up dependencies. [1]: https://velovix.github.io/post/lgpl-gpl-license-compliance-w... [2]: https://github.com/indygreg/PyOxidizer/issues/142

Bundling Python isn't too bad if you find the right tools for it. I really like https://github.com/indygreg/python-build-standalone and https://github.com/indygreg/PyOxidizer A bundled, built standalone Python can be 16 to 32MB (including the full standard library, which you can strip down to just the bits you use to save size). Not tiny, but probably not worth switching programming languages over.

XAR signing is effectively just an RFC 5652 CMS signature plus some minimal data structure manipulation. Code at https://github.com/indygreg/PyOxidizer/blob/faa7dfcea5d66bf5.... Mach-O and bundles, by contrast, require a myriad of additional data structures requiring thousands of lines of code to support. To my knowledge, nobody else has implemented signing of these far-more-complicated primitives. (Existing Mach-O signing solutions just do ad-hoc signing and/or don't handle Mach-O in the context of a bundle.)

As far I can tell, you can compile the binary and sign your app. # From a Git checkout $ cargo run --bin rcodesign -- --help $ cargo install --bin rcodesign # Remote install. $ cargo install --git https://github.com/indygreg/PyOxidizer --branch main --bin rcodesign apple-codesign

My favorite is the fairly new, but excellent PyOxidizer: https://github.com/indygreg/PyOxidizer It's written in rust and can embed resources and dependencies in the executable.

I don’t know it’s current status but either PyOxidizer or Nuitka are the two Python compilers I’d look to for that. It is full of trade offs, but to an extent that’s many dynamic languages like Python (said as a Python developer) https://nuitka.net https://github.com/indygreg/PyOxidizer

There is a Rust code-signing implementation. https://github.com/indygreg/PyOxidizer/tree/main/tugger-appl... Whether you should teach Rust to code-sign your software using this code is probably a tricky question, but it appears to me that you could.

Thanks for the links - pyoxidizer looks promising with some good docs and being built on rust (but it won't work with QT's PySide2 likely until the next major release[0]), while briefcase looks to have been tailored to "beeware" usage and is lacking any standalone usage information. Hoping both these work out, PyInstaller works but other options would be welcomed. 0: https://github.com/indygreg/PyOxidizer/issues/228#issuecomme...