#2549 feat: added build package script

[gotev]

@falkoschindler added the script as per your instructions in #2549. The script is meant to be copied and used as a base package build script for nicegui users, who will need to also modify it for their own specific usage (e.g. adding resources, icons and so on)

[falkoschindler]

Thank you for the pull request, @gotev!

I just reviewed the code and refactored it a bit to organize common and platform-specific arguments more intuitively. And I introduced argparse to allow configuring the parameters from outside.

What do you think so far?

I wonder if we really need to call pyinstaller without python -m on Windows... And what's the reason for the extra --onedir? There might already be an explanation in one of the issues and discussions, but I honestly lost track of every detail. Good to have this script to capture them all! 🙂

[gotev]

Great @falkoschindler ! Now I understood your idea better. I thought we wanted to give a basic build script from which to start for our users, but you intend to completely wrap PyInstaller. Some considerations and questions which came to mind:

• Won't we end up having our users creating their own python scripts invoking ours, where we could simply give them a simple starting point which they can configure as they see fit, without wrapping PyInstaller?
• From an OSS community standpoint, when something goes wrong during the packaging, we may end up receiving a lot of issues, which in reality belongs to PyInstaller. I speak from experience. When I wrapped something, even slightly, I ended up handling other projects issues or proxying them in the best case. It's a choice.

Then, regarding the updated PR:

• On windows python -m PyInstaller simply fails, not finding the PyInstaller on most recent python 3.x versions, so I had to resort to that workaround. I suspect it's something specific in how python is implemented on Windows.
• I think the '--add-data', f'{Path(nicegui.__file__).parent}{os.pathsep}nicegui', command should be part of the bundled-in extensions to the pyinstaller command, because without it the nicegui app won't work. As it is now, it will be completely overwritten if a user needs to add custom data.
• --onedir may be something left over from some of my tests. I'll check again to confirm you what happens if I remove it, because by reading PyInstaller docs, it seems to be the default option if one doesn't specify anything. I usually prefer to still specify it just in case the community decides to change the default (very unlikely though).

[falkoschindler]

@gotev You're right, we should be careful not to suggest or promise to wrap PyInstaller in all its glory, but to only give a starting point from which our users can deviate. I just thought it would be nice to have an executable documentation for how to package a NiceGUI app that is actually shipped with the library and which you can simply call for simple use cases.

(In the future) we can use it to guide the user to the most important arguments to consider and include some hints, either in the help text or in form of console output, like "1. Make sure to set native=True...", "2. Note about packaging on macOS: ..." and so on.

Regarding the --add-data argument: It should already work as expected, i.e. nicegui is always added while you can additional data:

$ ./pack.py --add-data /foo --add-data /bar --dry-run main.py
python -m PyInstaller --name Your App Name --add-data /Users/falko/Projects/nicegui/nicegui --add-data /foo --add-data /bar --windowed main.py

[gotev]

Got it, so let's proceed then. If we have a way to validate what the user is passing in ui.run before starting the packaging, it will be great, so we could simply fail the build printing out messages like native=True is required and so on.

Another useful thing we could add is to print out the full PyInstaller command before executing it, so it's clear we're providing a helper rather than a wrapper, reducing frictions for simple use cases and already giving the starting command for more complex scenarios. In this case I'd always print out the command and then terminate the script before executing it if dry run option is passed.

[falkoschindler]

I like the idea of always printing the command!
Detecting whether native=True is set could be challenging though. Users could make it dependent on some other flag like native=PRODUCTION, so that scanning for the string "native=True" is not enough. But we can postpone this feature and just print some short info text for now.

[gotev]

Agreed!

As an idea to achieve that, we could detect if the app is running inside a pyinstaller package at runtime:

import sys

def is_pyinstaller():
    return getattr(sys, 'frozen', False) or hasattr(sys, '_MEIPASS')

and validate run params. But that's for another PR 😉

[falkoschindler]

I just looked into this PR and noticed some remaining points we need to address:

• Regarding our idea about checking for native=True: The documentation recommends using --windowed only with native=True. Conversely, we don't need native=True if --windowed is not set. So I wonder if we really should set --windowed by default. Maybe we don't set it, but add a new argument --windowed for pack.py with a description taken from the NiceGUI documentation.

• Same for --onefile: We should add it as an argument with a description from the NiceGUI documentation.

• We should add the remaining packaging tips to the help text.

• We should warn about not packaging with reload=True.

[falkoschindler]

Ok, I added some more documentation to the pack.py script. Let's merge and improve it later.