Question regarding program call

[docjc]

Hi there,

I'm facing a problem:

I have build a python program with a PyQt6 Gui from which I call Sigil with
a subprocess function to start with a certain epub file to edit.
When I start the python program directly everything is fine. When I compile
everything I get the following error:

This application failed to start because no Qt platform plugin could be
initialzed. Reinstalling the application may fix this problem.
Available platform plugins are: minimal, offscreen, windows.


Is there anything I can do to avoid this????

Thanks for any positive answer

[KevinH]

You did not say what platform you are using?

Sigil in Windows and macOS embeds its own Python interpreter and its own PySide6 version. If those two Qt versions differ then issues arise. On Linux, there is a script to set the ld library path and other sundries.

That said, passing a path to an epub as the first argument to Sigil works well on all platforms.

So why not a shell or batch file to launch Sigil passing in the path to the epub you want to edit if simply adding it on the command line is an issue.

Or try creating a python subprocess with its own shell to invoke Sigil.

[DiapDealer]

Whatever you're using to freeze/compile your Python program may not be properly including/handling the necessary Qt dependencies/locations. Python compilers typically require special configs to deal with (Py)Qt.

From your description, it's hard to tell whether it's your compiled Python program that's failing to find Qt, or Sigil itself. The fact that you say everything works without freezing your python program suggests to me that it's the former.

It's also possible that the freezing involves setting certain Qt runtime environment variables that could definitely break Sigil's ability to find it's own Qt elements.

Using a compiled Python/Qt program to launch another C++/Qt program via a subprocess is always going to be fraught with peril (because of the environment the subprocess inherits). You're probably going to have to find a way to sanitize the environment used by the subprocess launching Sigil.

[docjc]

@KevinH

Originally Posted by KevinH

You did not say what platform you are using?

...

That said, passing a path to an epub as the first argument to Sigil works well on all platforms.

So why not a shell or batch file to launch Sigil passing in the path to the epub you want to edit if simply adding it on the command line is an issue.

Or try creating a python subprocess with its own shell to invoke Sigil.

Hi,
thank you for quickly answering

I forgot to say it is windows 11 PyQt6 latest version (maybe I should switch to PySide)

As I said, running as a python file works fine, no problem. Using PyInstaller to "compile" is the problem. As the epub file is defined during the process the batch file must also be generated during the process. I will try to do so. I have had the same idea generating to own shell for Sigil, but this gave the same result as before.

I'll keep you informed

[DiapDealer]

To be clear: when, exactly, does the error occur?

When you try to launch your PyInstaller-compiled program?

Or when you try to launch Sigil from your already successfully running PyInstaller-compiled program?

If it's the former, you might need to research how to include your qt plugins folder with your PyInstaller build.

[docjc]

The issue starts when I call sigil. I have tried to call Sigil via batch file and in an extra shell, nothing works really. Normally 2 different instances of Qt at the same time are working (Sigil and Calibre on the same computer, but different shells). So for me it is not quite clear how to separate the Python/Qt shell from the Sigil/Qt shell. I did it via subprocess(…..shell=True), is there a better way?

[docjc]

additionally I have to mention that the error message is coming from Sigil after calling Sigil by "subprocess.Popen([sigil_path, epub_file_path], shell = True)". Running the py file gives no error and everything is fine.

[DiapDealer]

I've rarely found a need for shell=True on Windows myself.

The described behavior still makes me think that part of PyInstaller's PyQt6 freezing strategy involves setting some Qt environment variable(s). You could try dumping the environment to a msgbox (before the subprocess call to launch Sigil) and look for something like QT_QPA_PLATFORM_PLUGIN_PATH. That would definitely cause issues if set. If it is, you could pass a sanitized env parameter to the subprocess.Popen call with all Qt/Python environment variables removed.

Something else to try is passing the cwd parameter to the subprocess.Popen call and setting it to Sigil's program directory (making sure to use a relative path to Sigil's exe rather than the full path).

[DiapDealer]

Did a quick test and PyInstaller definitely creates a slightly different env when compiled than it does when running as a script. It prepends an extra item to the PATH variable, and also sets the QT_PLUGIN_PATH to its own PyQt6 plugins folder. THAT will definitely affect Sigil adversely when launching via a subprocess. You'd need to scrub that (and the QML2_IMPORT_PATH for good measure) variable from a copy of the system environment and pass that via the env parameter to subprocess.Popen().

Hope something there helps.

[docjc]

sorry for not answering earlier, something else to do
Thank you for your efforts to solve the problem, This morning I did something else: I used calibre-edit.exe instead of sigil and this works fine even after compilation. After reading your mails I've got the idea to add sigil to the path and call just sigil and not the full path. I will try this and keep you informed.

[docjc]

The idea with the path wasn't successful, now I will try your proposal

[DiapDealer]

Originally Posted by docjc

sorry for not answering earlier, something else to do
Thank you for your efforts to solve the problem, This morning I did something else: I used calibre-edit.exe instead of sigil and this works fine even after compilation.

Kovid patches his Qt so the plugins path can be set before calibre runs. We typically only patch what's necessary to fix Qt bugs that adversely affect Sigil.