pyside6-designer launcher is absent

adrianghc

I'm trying to replicate on Arch Linux but after installing pyside6 via pacman (and installing "which"), I cannot actually find the designer binary. I'm generally very surprised you'd find designer with that plain name without pyside6 prefix in /usr/bin, not the least because that file doesn't seem to be installed according to https://archlinux.org/packages/extra/x86_64/pyside6/. Did you do anything else besides pacman -S extra/pyside6?

pyside6-assistant is a bundled tool just like designer, so in order to troubleshoot the problem I was trying to find out whether there is any difference in the behavior you describe between our bundled tools. pyside6-designer is part of the main pyside6 package, yes, and so is pyside6-assistant. What happens if you run pyside6-assistant or assistant, or which assistant?

StarterKit

Hi @adrianghc,
It appears you stepped in a right way and I'm sorry to say that I created this mess and forgot about it after an upgrade to Qt6 about year ago. It wasn't fully ready and stable so I kept some packages... And you opened my eyes now:

[user@pc ~]$ which designer
/usr/bin/designer
[user@pc ~]$ pacman -Qo /usr/bin/designer
/usr/bin/designer is owned by qt5-tools 5.15.7+kde+r1-2
[user@pc ~]$

The same I see in UI menu of Designer: Help->About Qt shows me 5.15.7.

With regards to assistance - I have exactly the same situation: the assistant is from 5.15.7 and pyside6-assistant is missing.

I assume the next step is to remove qt5-tools 5.15.7+kde+r1-2 and find the right package for qt6. Most probably it should fix the problem. I'll let you know later (but it might be I'll to to Arch forums/mainteiners to reveal where qt6 designer lives)

StarterKit

Ok, an attempt to remove qt5-tools was not successul as it is required for things like vitrtualbox...
But I found that I have qt6-tools installed already that actually provides me with things like /usr/bin/designer6, /usr/bin/assistant6 etc.

It appears that neither https://archlinux.org/packages/extra/x86_64/qt6-tools/ nor https://archlinux.org/packages/extra/x86_64/pyside6/ provides pyside6-designer launcher on ArchLinux. But where it should originally come from to one of these packages?

adrianghc

I must admit I'm not familiar with the Arch packages, I only knew what they were supposed or not supposed to contain after I opened the file lists. The picture is much clearer now, though.
pyside6-designer etc. are included if you install pyside6 via pip, in which case it would lie inside the bin directory of the Python environment you installed it in, see question 4 of my first response.
There should be no difference between pyside6-designer and designer6 installed via qt6-tools so if installing PySide via pip is not an option you could just use the latter binary.

StarterKit

@adrianghc said in pyside6-designer launcher is absent:

There should be no difference between pyside6-designer and designer6 installed via qt6-tools

Are you sure in this statement? I should that pyside6-designer should be some kind of script (that calls actual designer binary)... but I see that designer6 is a binary file.

adrianghc

~~There should be no difference between pyside6-designer and designer6 installed via qt6-tools~~
There should be no difference between the designer binary called by pyside6-designer and designer6 installed via qt6-tools

🙂

StarterKit

@adrianghc, okey... I still have some doubts but I should give it a try :) - will try to create simple widget next week

adrianghc

I just checked and while not the Arch package, the designer and assistant binaries are identical between the full Qt installation (from the Qt Online Installer) and PySide from pip on my system. 👍

Happy holidays, and good luck with the widgets next week. 🙂

StarterKit

@adrianghc Merry Christmas to you! :)
But my custom widget jorney isn't successful so far... What I did:

Starting from this page I took Task Menu Extension (Designer) example.
As there was no any register*.py file with registerCustomWidget() call I decided to create my own. As DOM_XML is already defined in tictactoeplugin.py my file is pretty simple:

from tictactoeplugin import TicTacToePlugin, DOM_XML

import QtDesigner

QPyDesignerCustomWidgetCollection.registerCustomWidget(TicTacToePlugin, module="tictactoeplugin",
                                                       tool_tip="Custom Widget", xml=DOM_XML)

I set PYSIDE_DESIGNER_PLUGINS environment variable to point to the directory with example. And then ran designer6 from the same command line. The result is nothing, no new widgets are visible in Widget Box :(
As "Troubleshooting the Qt Designer Plugin" section says I went to Help/About Plugins menu and there is an error indeed:
Cannot load library /usr/lib/qt6/plugins/designer/libPySidePlugin.so: (/usr/lib/qt6/plugins/designer/libPySidePlugin.so: undefined symbol: PyImport_AddModule)
The library itself is present in my filesystem:

[user@pc designer]$ file /usr/lib/qt6/plugins/designer/libPySidePlugin.so
/usr/lib/qt6/plugins/designer/libPySidePlugin.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8cf43238963aab8d4f447e10d026898855e005f4, stripped

From the name of file I see that error is related with PySide so I strongly suspect that I need to fix it before any further attempts... But I have no idea what I may do to fix it...
My only suspect is - this part of manual was missed when Arch-package was compiled:
When building Qt for Python, be sure to set the --standalone option for the plugin to be properly installed.
as /usr/lib/qt6/plugins/designer/libPySidePlugin.so is owned by pyside6 6.4.1-2

StarterKit

Meanwhile I tried the same on Windows.
Plugin was loaded successfully and appeared in new Custom widgets tab of Widget Box.
Menu Help/About Plugins shows that PySidePlugin.dll was loaded successully and TicTacToe appeared under it.

So it appears to be a problem of Arch Linux setup...

StarterKit

The story continues so I would like to keep this topic updated.
The problem with libPySidePlugin.so import was indeed specific to pyside6 package of Arch Linux and fix was done in pyside6 6.5.1.1-2 release yesterday.

Now there are no errors in Help/About Plugins menu but there is an error in console instead:

[user@pc]$ PYSIDE_DESIGNER_PLUGINS=/home/projects/widget_plugins/ 
[user@pc]$ export PYSIDE_DESIGNER_PLUGINS 
[user@pc]$ designer6 
PySide6/__init__.py: Unable to import Shiboken from /home/projects/widget_plugins, /usr/lib/python311.zip, /usr/lib/python3.11, /usr/lib/python3.11/lib-dynload, /usr/lib/python3.11/site-packages 
qt.pysideplugin: Error running /home/projects/widget_plugins/register_designer_plugins.py: /usr/lib/python3.11/lib-dynload/binascii.cpython-311-x86_64-linux-gnu.so: undefined symbol: _PyUnicode_Ready 
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.

It prevents plugin from loading and seems to be a PySide bug...

StarterKit

And finally it was found that pyside6-designer is included in PySide6-Essentials package that seems to be absent for Arch Linux but was installed on my Windows OS.

So this is a solution for Linux - you need to install PySide6-Essentials (for Arch Linux it was fixed in package pyside6 6.5.1.1-3)

But the wrapper itself is rather simple so it appears to be useful even without installation:

import re
import sys
from PySide6.scripts.pyside_tool import designer
if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
    sys.exit(designer())

CristianMaureira

@StarterKit The main issue here was that the packages provided by different OS are adapted for their needs. We ship Qt for Python officially in wheels, so we expect that the use case is that you create a virtual environment, and pip install pyside6 there and develop your application. The PySide that come in Arch, and other distros don't have a similar structure nor the same goal for users, so I'd always recommend you not to install Python module system-wide and keep them in your virtual environments.

StarterKit

Hi @CristianMaureira, yes this is clear.
But it is much more convenient to have all your packages managed by a single packet manager. This is the reason why I prefer to use system-specific packages in case of Arch.
So as result Arch package was improved and I think it is an acceptable outcome.