Closed Geegee closed 2 years ago
You did not show the actual error here, can you post that? Where do you get your Python from? System Python or Miniconda?
The only place where the path could differ from the qudi process is here
I think subprocess.run
can be configured accordingly. That's the place where I would start searching for the bug.
Thanks for pointing it out. I put the error message under the 'log output' section now, sorry.
On 2/7/22 12:58, Jan Binder wrote:
You did not show the actual error here, can you post that?
— Reply to this email directly, view it on GitHub https://github.com/Ulm-IQO/qudi-core/issues/12#issuecomment-1031387861, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVMTINXMTWTZ6IJPJHWDODUZ6XXPANCNFSM5NXGQBOA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
Python sys.path is not really $PATH.
jan@janvision:~$ echo $PATH
/home/jan/.local/bin:/home/jan/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
jan@janvision:~$ python3
Python 3.9.10 (main, Jan 16 2022, 17:12:18)
[GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib/python39.zip', '/usr/lib/python3.9', '/usr/lib/python3.9/lib-dynload', '/home/jan/.local/lib/python3.9/site-packages', '/usr/local/lib/python3.9/dist-packages', '/usr/lib/python3/dist-packages']
>>>
We should also switch back to QtUiTools.loadUiType() instead of implementing UI compilation ourselves.
We should also switch back to QtUiTools.loadUiType() instead of implementing UI compilation ourselves.
Gladly... if this works now. My last attempt was over a year ago. This ugly workaround is not nice but I did not see another way back then.
A problem that will still remain however is having custom/promoted widgets in the .ui
file. Resource management is a bit of a pain in Qt with Python. E.g. making these .ui
files work when people can install qudi (addon-)packages anywhere on their system.
After trying commands like 'ls' etc. which also did not work I figured out that the path could not really be the cause
of these problems.
If I use:
result = subprocess.run(["pyside2-uic", f"{file_path}"], capture_output=True, text=True, check=True)
the GUI modules start without a problem. Why is the other syntax not working here? Is it maybe only working
for stdin?
The question is now if this change would break something on other platforms like windows?
Another thing which works is
result = subprocess.run("pyside2-uic '{}'".format(file_path), capture_output=True, text=True, check=True, shell=True)
Has been resolved by merging PR #18.
Version
v1.0.1
What is affected by the bug?
I tried using different versions of Pyside2 5.15.2.1 / 5.15.2 / 5.15.1 to no avail. Just running pyside2-uic "some-gui-module.ui" runs without error. As @kay-jahnke pointed out it seems like the environment qudi runs in does not have access to "pyside2-uic". Yet in the same terminal qudi is started from and in the same environment pyside2-uic can be run from the command line.
This shows the output when run sys.path within qudi:
The output where pyside2-uic resides
This is when run in the ipython console
It seems like qudi is modifying the path variable, which I am not sure how to fix at the moment.
When does the bug occur?
Trying to load Gui modules with a "*.ui" file.
How do we replicate the issue?
Seems to occur only on Linux.
Expected behavior
Create a uic file.
Relevant log output
Exception during activation:
Additional Comments
No response
Contact Details
wgolff@googlemail.com