This could be tricky, but I'd like to suggest moving the PyLNP source outside of the executable (i.e. making the executable only consist of the Python interpreter, libraries, and whatever else is necessary to run the PyLNP source). Although it's not as easy as importing a module directly, Python allows loading source files from a specific path, so the executable could consist of a simple launcher that locates and loads the "main" PyLNP source file, from where other imports should work. Some advantages:
* The executable wouldn't change between versions (this would help avoid antivirus issues)
* Packs can distribute new versions of PyLNP without having to rebuild the executable again (or relying on it to be rebuilt by someone else if they don't have a build environment on specific platforms)
Starting July 22, I will not have access to my main development PC for a couple of months. This is going to limit my ability to participate in development, and it is highly likely that I will be unable to post builds.
<snip>
Pack maintainers: If important changes are made during this period, and you wish to include them in your pack, you will most likely need to build your own executables.
Also, if we can move auxiliary files out of the executable, that would address issues like
this, where the xdg-terminal script embedded in PyLNP is non-portable and I have no easy way of fixing it, even though a fixed script has been present in the Linux LNP repo ever since that issue was reported.
I'm unfamiliar with PyInstaller, but all this would involve would be ignoring all source files except the launcher script (which should probably import all modules that the pack needs, so PyLNP bundles them), then including those source files in individual packs in a designated (sub)folder. Adding compiled Python libraries might require a new build of the executable (but that would be much less frequent than rebuilding it every release), but source-only libraries (and maybe binary libraries) could also be distributed externally if the launcher modifies sys.path appropriately. (The launcher could easily read from a config file to figure out these paths.)