I've started the work on this, but it's rather complicated. The package has 3 python libraries in it as well as some other binaries. I took the pyside2 spec as a "base", I'll try to look into it this week. Might need help from the python folks in matrix.

Right now I'm stuck on two points:

1- Multiple python libraries in one packages: The pyproject macros dont handle this properly and I'd need to find a way around it
2- For a certain reason it's also failing to find a bunch of python executables that don't seem to be packaged in Fedora

Don't use the file list macros to avoid point 1, and I don't know what you mean in point 2?

Those are the errors:

[WARNING]: /usr/libexec/uic not found. pyside-uic not included.
[WARNING]: /usr/libexec/rcc not found. pyside-rcc not included.
[WARNING]: /usr/libexec/qmltyperegistrar not found. pyside-qmltyperegistrar not included.
[WARNING]: /usr/libexec/qmlimportscanner not found. pyside-qmlimportscanner not included.
[WARNING]: /usr/libexec/qmlcachegen not found. pyside-qmlcachegen not included.
[WARNING]: /usr/bin/lupdate not found. pyside-lupdate not included.
[WARNING]: /usr/bin/lrelease not found. pyside-lrelease not included.
[WARNING]: /usr/bin/qmllint not found. pyside-qmllint not included.
[WARNING]: /usr/bin/qmlformat not found. pyside-qmlformat not included.
[WARNING]: /usr/bin/assistant not found. pyside-assistant not included.
[WARNING]: /usr/bin/designer not found. pyside-designer not included.
[WARNING]: /usr/bin/linguist not found. pyside-linguist not included.

I was trying to find those files with dnf, some I can find but in a different path.

Hi everyone,

I'm kinda new to the Fedora land. I come here wearing my maintainer hat for Dangerzone, where we offer RPM packages to our users that depend on PySide2. Since Fedora 39 though, PySide2 is no longer in the repos (and that's good), so we want to package PySide6. Neil pointed me to this issue (original discussion: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2255537) and I must say it's great to see this getting more traction.

Now, regarding the above comment. While packaging PySide6, we also encountered similar errors. In our case, I consulted both the existing PySide2 package and spec file, as well the PySide6 package that OpenSUSE offers (spec file). From my understanding, those files were not shipped before, so it's fine removing them from the main PySide6 package.

Hey there,
sorry for not being aware of this before, but it was raised on a KDE discussion.

Yes, many python modules are built when you use the 'setup.py' approach, because in the past we wanted to simplify the build process. We are aware that currently is not a standard approach, but splitting the process is a bit complicated.
In a nutshell, when 'python setup.py build ...' is called, the process will run 3 times, one for shiboken6 (module), one for shiboken6 (generator) and the last one for pyside6.
You can build only of of those passing the argument --internal-build-type=shiboken6_generator for example.

Other distributions, for example Archlinux followed the CMake approach https://gitlab.archlinux.org/archlinux/packaging/packages/pyside6/-/blob/main/PKGBUILD?ref_type=heads which you can also can do focusing on the source/ directories.

Now, the story related to the executable you mentioned @ngompa is because we bundle all those Qt executables into the PySide6_Essentials package, because one of our stronger use cases is Python developers without any Qt installation.
We use the entry_points of the wheel in order to use an ad-hoc script to, for example create venv/bin/pyside6-uic which as a python script pointing to venv/lib/python3.x/PySide6/uic [args]
You could safely create bash scripts to alias the tools, like:
* pyside6-uic = uic -g python
* pyside6-rcc = rcc -g python
* etc
Please notice that some tools have a special treatment for handling other configurations besides just calling a script, like the designer, but you can see them on that pyside6_tool.py file.
So, as long as Qt6 is a dependency of pyside6, you could rely on those binaries being on the system, so you can safely call them.

Related to what you mentioned @apyrgio in PySide2, there was an outdated version of 'uic' and 'rcc' in order to approach the behavior of the tools, so there pyside2-uic and pyside2-rcc were real applications. We decided to drop them because now those tools are not required, because Qt's uic and rcc now support python with the -g python option.

If you have any further question, you can reach us on different platforms https://wiki.qt.io/Qt_for_Python#Community people is more active on telegram, but we have it bridged with irc, so if that's your jam, you can ping us there :) and of course, in case you believe something is super wrong, drop by our bug report platform: https://bugreports.qt.io/projects/PYSIDE/

Thanks for the time you are investing into packaging pyside6, we will do our best to help you from our side.

So @loise started packaging it and submitted a review in rhbz#2265554, and we've noticed that it seems to fail with gcc. Do you have any idea what's going on here? :frowning:

So @loise started packaging it and submitted a review in rhbz#2265554, and we've noticed that it seems to fail with gcc. Do you have any idea what's going on here? :frowning:

i think now it's time for testing stuff first and see how far we get, the first thing would be to package examples and create the docs for qt-creator and see if you can actually work with it :)