Binary builds for Mac and Windows

[glowinthedark]

Now that v5.0.0 is out the idea was to create native binary builds with all possible dependencies already included. So far didn't manage to generate functional packages using github workflows as nuitka seems to choke while trying to figure out the dlls that needs to be linked in order to make a standalone app.

These are nuitka tk-based generated builds on actual hardware, nuitka builds to native code so there is no actual python interpreter, it's all converted to cpp and compiled to native, and python is only present as a DLL:

• https://github.com/glowinthedark/pyglossary/releases

the dirty WIP scripts that were used to generate these builds:

• windows: https://github.com/glowinthedark/pyglossary/blob/nuitka/build-exe-nuitka.cmd
• macos: https://github.com/glowinthedark/pyglossary/blob/nuitka/build-mac-nuitka-tk.sh

Unfortunately, the scripts are not very reliable and far for 100% reproducible in a generic scenario, so far couldn't bring them to a proper shape that would be good enough for a proper pull request since it's very likely they will fail depending on each specific environment.

If you manage to get the scripts to work in your env maybe you'll want to add the artifacts to the release?

[glowinthedark]

pyglossary on google colab

..not really belonging in this thread, just fyi since don't have other context to put it into: it's relatively easy to run pyglossary in the cloud for example with google colab

[glowinthedark]

scripts for building the windows Inno installer:

• https://github.com/glowinthedark/pyglossary/blob/nuitka/build-inno-setup-installer.cmd - this one just runs "c:\Program Files (x86)\Inno Setup 6\ISCC.exe" inno_setup.iss
• inno_setup.iss - the actual script for Inno

If needed I could make a pull request with these, but again, they are part of a build process that is not 100% reproducible in some controlled env such as such properly configured github runner, or something docker-like so not sure it would make any sense.

[ilius]

• inno_setup.iss - the actual script for Inno

Is this file generated?
It points to your C:\Users\xh.
Also what is "C:\Users\xh\projects\pyglossary\build.PyGlossaryWinNuitka\main.dist\*"?
That directory is not created.

[glowinthedark]

Is this file generated?

the skeleton was originally generated by the Inno Setup Wizard and then manually tweaked. Didn't try using relative paths, probably that would work too, used absolute path since it is just a proof of concept stage, I suppose a clean final version would probably need to use a dedicated subfolder under the project root, and build the artifacts in that subfolder rather than directly in the root.

Also what is "C:\Users\xh\projects\pyglossary\build.PyGlossaryWinNuitka\main.dist\*"?

build.PyGlossaryWinNuitka\... is the custom OUTPUT_DIR see 🔗 that is passed to nuitka ... --output-dir="%OUTPUT_DIR%" main.py see line 21 and the main.dist is derived by nuitka from main.py.

See also https://nuitka.net/doc/api-doc.html#nuitka.Options.getOutputDir

[glowinthedark]

@ilius: btw, actually there is no need to explicitly define --output-dir="%OUTPUT_DIR%" for nuitka, if omitted it will use a default folder name; I only added it because was also experimenting with pyinstaller too, and it was confusing as to which build.xyz and dist.xyz was created by which tool.

Also, for the macos builds specifying the final binary name apparently is not supported by nuitka when using --standalone mode (i.e. no dependencies mode), therefore before the build I am copying main.py to something like PyGlossaryTk.py and passing it to nuitka as the entry point in order to force it to use this name.. it's ugly, but it's cheap. 😄

[ilius]

I'm gonna be honest.
I don't want to be involved in operating system packaging.

Even if you can fully automate building Windows / Mac executables, it needs to be built on every release and tested manually (at least periodically).
I'm not going to run a Windows VM (let alone Mac) on every release, to build and test it, for years to come.
My time is better spent on development.

If you are interested, you can work on automating it in a new repo. Perhaps even running it with GitHub actions.

[glowinthedark]

@ilius:

I'm gonna be honest.
I don't want to be involved in operating system packaging.

In fact, the intent was just to let you know that it's feasible and doable — it's kind of cool that the project can be compiled to native binaries without python dependencies and without an interpreter (with python as a DLL); as well as make this info available to whoever might be searching for it; I totally understand and fully support your position that packaging is out of scope specifically for this repo — binary releases always involve questions about security and privacy as well as stability in terms of portability for each and every OS version, and therefore it's a PITA in terms of support and maintenance; imo it's best to let the users do it on their own (if they really need it), and that's how I see open source projects should be like. I have seen complaints from non-programmer users that pyglossary is too tricky to get working, especially with support for formats that require a full blown and properly configured compiler environment for modules like lzo and icu and that was part of my motivation to try to make it easier for those users.

I did try to automate the build process using github actions but nuitka doesn't seem to work as expected with the github ootb runners, even though the nuitka author does provide a dedicated github action; or at least it doesn't seem to play well with pyglossary as it is currently structured; so I am not gonna spend more time on this.

I'd say that the rough build scripts linked above are sufficient as a starting point for anyone who wants to compile binary builds on their own hardware, so no extra action is needed.

Also, I plan to periodically create updated builds in my fork that contain all the python dependencies for whoever might need them so that anyone can use them at their own risk.