Unable to start UI when invoked as a module

[denravonska]

Description

Branched off from #181

It seems that when invoking your code as a module (python -m ...) it triggers the same error as having the incorrect main guard, even when not using any guards.

You must call ui.run() to start the server.
If ui.run() is behind a main guard
   if __name__ == "__main__":
remove the guard or replace it with
   if __name__ in {"__main__", "__mp_main__"}:
to allow for multiprocessing.

ERROR:    Application startup failed. Exiting.

Small sample project setup at https://github.com/denravonska/nicegui-error-sample.

[falkoschindler]

Hi @denravonska, thanks for reporting this issue!

In the case reload=True (the default), NiceGUI assumes that the child process runs ui.run so that it gets all parameters like the main process did. But in the case of running __main__.py via python -m, the script isn't evaluated a second time, thus ui.run isn't called in the child process. The file __main__.py acts like a large main guard.

Unfortunately, I don't know how to fix that. Does any else have an idea?

[denravonska]

Hi @denravonska, thanks for reporting this issue!

In the case reload=True (the default), NiceGUI assumes that the child process runs ui.run so that it gets all parameters like the main process did. But in the case of running main.py via python -m, the script isn't evaluated a second time, thus ui.run isn't called in the child process. The file main.py acts like a large main guard.

Unfortunately, I don't know how to fix that. Does any else have an idea?

Thanks for looking into this. I figured it was something non-trivial related to outside circumstances. For now I'll run the code as an application instead of a module as a workaround. I'll yell if I happen to stumble upon a solution for this.

[falkoschindler]

I converted this issue into a feature request because it's not really an issue with the existing feature set. But of course, it would be nice to add support for it in the future. If anyone has an idea how to achieve it, we're all ears. 😀

[ed2050]

@falkoschindler Is this still an issue? Perhaps this may help.

I once had a problem with creating a listener process exactly once. Couldn't use __main__ because the code that created it might be loaded as a module. Couldn't create listener every time module was loaded because it was imported by multiprocessing apps that spawn children. I needed a flag that could be set exactly once across a main process and it's children.

Solution: environment variables. Set env variable when code first runs and creates listener. Spawned child processes inherit environment. Repeat loads of module in children check for env variable and know listener has already been created.

This situation is a bit different. But the principle of using env vars to pass info to children could work. Perhaps ui.run can set an env var with name of module / function that invoked it? When watch restarts the process, something can read that env var to know which function started ui.run. You won't have process state though, if that func takes any args.

If you need to save more state, perhaps you could use pickle and the fileystem? Save a file like ~/.appname.PGID.pkl where PGID is the process group id. Dump whatever state you need in there. On reload, look for the file (PGID should be unchanged) and load state.

Would that help? Without knowing the precise reload call sequence, perhaps I missed something.

More detail on previous solution here:
https://stackoverflow.com/questions/7989123/importing-modules-that-use-multiprocessing-python/76929437#76929437

[falkoschindler]

That's an interesting point, @ed2050!
But I'm not sure how to use it when running a NiceGUI app as a module. 🤔

[MrGibus]

As a workaround.
You can run this as a module by setting ui.run(reload=False)
If you want to also be able to run with reloading while developing, you can set up a separate script that just calls ui.run()

[pycaw]

Running into this was kinda my first impression of using NiceGUI.

uv run mypackage, with

[project.scripts]
mypackage = "mypackage.__main__:main"

which has __name__ == "__main__" guard in it which prevents the secondary process from reaching ui.run (__name__ is mypackage.__main__ not __main__ in such instances). Not having it would limit the usability of the package.

I added a,

[project.scripts]
mypackage-dev = "mypackage.app:run"

but currently I'm quite clueless as to how package organization should go from the aspect of what should be reloaded. I imagine only reloading the ui logic is the way to go. But, that... will bring in weird constraints sooner or later. I would appreciate someone pointing to info exactly on this.

[rodja]

I'm not quite sure, but might this better be discussed in a new feature request titled "Add uv example" or similar?

[pycaw]

Other tools would process [project.scripts] similarly, and it threw me the same error this issue started out with. My question at the end was about package organization with reloading done the smartest way possible -- reloading only what you need but ideally without having to completely decouple ui and app logic (and avoiding the issue this thread talks about).

[pycaw]

Simplest solution is to have a mainguard like so:

from multiprocessing import current_process

if __name__ == "__main__" or current_process().name != "MainProcess":
    ...

As "__mp_main__" as hinted in the error message and noted in https://github.com/zauberzeug/nicegui/wiki/FAQs#why-is-my-code-executed-twice doesn't play a role with module based invocations.