Can't find Qt platform plugin after install from source

[jskat]

Hello @luigiferiani,

I downloaded the repository from ZIP, then successfully ran conda env create -f tierpsy_windows.yml #[Windows 10] conda activate tierpsy pip install -e . as described in the instructions.

However, when I run tierpsy_gui, the following error appears:

qt.qpa.plugin: Could not find the Qt platform plugin "windows" in "" This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

This is on a Dell XPS 13 with Windows 11. Any idea why this is happening?

[luigiferiani]

Hi, this may end up being a non-Tierpsy-specific issue. Some googling brought me here, where they seem to have a solution: https://stackoverflow.com/questions/41994485/

Let me know if that helps, and I'll add it to the Known Issues section.

That said, we've had multiple users have problems installing Tierpsy from source on Windows. Unless you have a strong need to make changes to the code Docker remains the preferred method of installation on Windows

[jskat]

Thank you!

First I tried conda remove qt conda remove pyqt conda install qt conda install pyqt which didn't work. Then conda install --force-reinstall pyqt, conda install --force-reinstall qt didn't work.

Then I uninstalled my Visual Studio build tools and reinstalled the full Visual Studio IDE. This created the error: command 'cl.exe' failed: No such file or directory issue, which I resolved as described in the known issues section.

Several of the other answers in that StackOverflow post don't seem to apply to this specific case - for example, one answer is targeted at people using PySide2.

I went Control Panel --> System and Security --> System (alternatively, Windows Key --> About your PC) --> Advanced System Settings --> Advanced tab (alternatively, Windows Key -->Edit the system environment variables) --> Environment Variables and added a system variable QT_PLUGIN_PATH with value C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins. This didn't work. But after exiting and starting a new conda session, it worked.

However, commenters on the post mention that this method will cause errors for programs like Dropbox. One method I wasn't able to try is described here and here (I think they're the same strategy). What would be the "project interpreter folder" in Tierpsy's case?

[luigiferiani]

Hi, sorry for the late reply, I was on annual leave.

PySide2 and PyQt are basically the same thing so I didn't think too much of there being examples for both in the stackoverflow link.

I'm glad setting the environment variable worked. I understand the concern that it might cause issues with other programs. If you're getting problems with that, a solution should be to set the environment variable temporarily, in a tiny script that activates the conda environment, sets the QT_PLUGIN_PATH variable and starts Tierpsy. This way, the env variable would not affect anything else in Windows. See here for the syntax to use and here and here for tips on how to make a batch script that uses the conda interrpreter (I did not test this, I do not have a windows machine on hand at the moment).

That said, this type of problems is what led us to develop the Docker installation option 😃

[jskat]

Thanks for the reply! I believe I've found a good solution.

First, I followed the windows section of this conda documentation on managing environments. In the Windows command prompt, I changed directory to C:\Users\myusername\miniconda3\envs\tierpsy and then copied the commands in the tutorial. The mkdir commands failed since the activate.d and deactivate.d folders already existed. Then I used Visual Studio Code to edit the files, so that activate.d\env_vars.bat contained

set MY_KEY='QT_PLUGIN_PATH'
set MY_FILE=C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins

and deactivate.d\env_vars.bat contained

set MY_KEY=
set MY_FILE=

This did not fix the problem. I'm not sure exactly what content needs to go in the batch files. I also tried and failed with

set QT_PLUGIN_PATH='C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins'

and

set QT_PLUGIN_PATH=

Nevertheless, this StackOverflow answer worked. But before starting over, I left the two env_vars.bat files unchanged and ran conda env config vars list -n tierpsy before, during, and after activation of the tierpsy environment. The output was blank, suggesting that my batch files were not doing anything.

Anyways, I deleted the batch files, activated the environment, and ran

conda env config vars set QT_PLUGIN_PATH='C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins'

After deactivating, the conda env config vars list -n tierpsy command produced output confirming that QT_PLUGIN _PATH = C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins. Then I activated the tierpsy environment again, and the tierpsy_gui command worked!

Interestingly, after applying this solution, the “Environment Variables” page (accessible via Windows key → “Edit the system environment variables” → "Environment Variables") does not display any system variable for QT_PLUGIN_PATH. So perhaps this solution eliminates compatibility issues with Dropbox. Regardless, issuing the command conda env config vars unset QT_PLUGIN_PATH within the Tierpsy environment unsets the variable (and causes the Qt plugin error to occur after reactivating the environment).

Perhaps the Qt plugin path error only occurs with Windows 11? When I initially raised this issue, I was using a Dell XPS 13 with Windows 11. Later, I installed Tierpsy from source on a Dell Inspiron 3583 with Windows 11, and still encountered the Qt plugin error. Notably, I did not encounter this error when I first installed Tierpsy from source on this same Inspiron 3583 running Windows 10 about 1.5 years ago. However, that was also with an older version of Tierpsy.

One last piece of good news: the StackOverflow answer suggests that the YML file can make this environment variable fix happen automatically!

[jskat]

TLDR: to fix the Qt error, activate the tierpsy environment and run conda env config vars set QT_PLUGIN_PATH='C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins', then reactivate the environment with conda activate tierpsy.

I modified my tierpsy_windows.yml file, adding the following two lines to the bottom of the file:

variables:
  QT_PLUGIN_PATH: 'C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins'

Then I deleted my Tierpsy environment and recreated it with conda env create -f tierpsy_windows.yml. Then I activated Tierpsy and ran pip install -e . followed by tierpsy_gui, which executed successfully.

However, the environment variable didn't disappear (based on conda env config vars list -n tierpsy) after deactivating the environment as advertised here. When I ran conda env config vars unset QT_PLUGIN_PATH and then reactivated the environment, the Qt plugin error resurfaced. I got rid of it the same way as before, using

conda env config vars set QT_PLUGIN_PATH='C:\Users\myusername\miniconda3\envs\tierpsy\Library\plugins'

Thus it seems that modifying the YML file is mostly unhelpful. I may be wrong.

EDIT: after reading the documentation more carefully, it seems that the environment variable isn't supposed to disappear after deactivating the environment. Rather, it stays around for that particular environment, but only affects that particular environment. So conda env config vars list -n base does not display the variable even though conda env config vars list -n tierpsy does. The YML file still doesn't seem extraordinarily useful since a single Anaconda command can accomplish the same task.

[luigiferiani]

Hi @jskat, it's great you solved the issue and thank you for the extensive testing. The .yml solution would to be honest be great, but I cannot assume I'll be able to get the right path for every user (e.g. some people use miniconda, others anaconda)...

I agree that the conda env config vars set command is most likely the best solution. I'll add a section to the troubleshooting section with a link to this issue.

So perhaps this solution eliminates compatibility issues with Dropbox. I'd very much expect this to be the case, yes.

Perhaps the Qt plugin path error only occurs with Windows 11 This is very possible too - I have not seen this on Windows 10. I don't have a Windows 11 machine to run tests on...

I'll close the issue for now - thank you :)