Hi, during a rebuild I noticed kf6 packages now have started to include the option to generate python bindings based on pyside6. I made some preliminary experiments (on epel9 so I needed a sed in %build to drop the python requirement from 3.10 to 3.9 to make it work, not needed on fedora) and here's the list for review where the bindings get build successfully and have them packaged. The goal would be to have that included in @farchord s sidetag as soon as possible so the next Fedora would be able to provide development of KDE plasma 6 apps in python:
Those 6 packages are all affected in release 6.10 where the python bindings are added to the build system.
The python bindings are a GSoC project: https://community.kde.org/GSoC/2024/StatusReports/ManuelAlcaraz The ki18 bindings aren't merged into the frameworks yet but available here: https://invent.kde.org/manuelal/pykde6
Is it just available on those 3 for now?
I'm going through all packages and saved the first three entries for a start :) I'm completing things now going trough all build logs of kf6
Metadata Update from @farchord: - Issue assigned to loise - Issue set to the milestone: Fedora Linux 41 - Issue tagged with: meeting, packaging
@loise suggested this might not be needed and asked to discuss this in today's meeting.
Let me know when the pyside6 packages are in epel10 and I'll get this in
pyside6 is in epel10.
The sed call is no longer needed since KDE lowered the requirements to 6.9, otherwise the RPMs look good to me.
I'd like this to be finished so I can add Fedora to the list in https://develop.kde.org/docs/getting-started/python/python-bindings/ :D
I rebased all prior rpms (and deleted the sed that is now unnecessary) and added https://src.fedoraproject.org/fork/loise/rpms/kf6-kstatusnotifieritem
So my count is 7 kf6 packages for now.
However my copr build work, the scratch builds don't :(
Anyone who can have a look at the logs and point to the possible causes ? E.g. here:
https://kojipkgs.fedoraproject.org//work/tasks/4547/130224547/build.log
cd /builddir/build/BUILD/kf6-kcoreaddons-6.12.0-build/kcoreaddons-6.12.0/redhat-linux-build/python/KCoreAddons && /usr/bin/python3.13 -m build --wheel --no-isolation Getting build dependencies for wheel... Traceback (most recent call last): File "/usr/lib/python3.13/site-packages/pyproject_hooks/_impl.py", line 402, in _call_hook raise BackendUnavailable( ...<4 lines>... ) pyproject_hooks._impl.BackendUnavailable: Cannot import 'setuptools.build_meta' ERROR Backend 'setuptools.build_meta:legacy' is not available. gmake[2]: ** [python/CMakeFiles/KCoreAddons.dir/build.make:1026: python
PRs for review: https://src.fedoraproject.org/rpms/kf6-kcoreaddons/pull-request/5 https://src.fedoraproject.org/rpms/kf6-kguiaddons/pull-request/4 https://src.fedoraproject.org/rpms/kf6-kwidgetsaddons/pull-request/4 https://src.fedoraproject.org/rpms/kf6-knotifications/pull-request/3 https://src.fedoraproject.org/rpms/kf6-kstatusnotifieritem/pull-request/5 https://src.fedoraproject.org/rpms/kf6-kunitconversion/pull-request/3 https://src.fedoraproject.org/rpms/kf6-kxmlgui/pull-request/3
@herzenschein all 7 fixed and comitted so packages should show up tomorrow
The whl toml file gets generated in the build dir and the wheel built there at the end of each build, the build items except the wheel removed, is that supposed to stay that way ? If I want to finish that up correctly, I need to copy that outside the build and then re-build the wheel a second time if I see this right ?
@herzenschein all 7 fixed and comitted so packages should show up tomorrow The whl toml file gets generated in the build dir and the wheel built there at the end of each build, the build items except the wheel removed, is that supposed to stay that way ? If I want to finish that up correctly, I need to copy that outside the build and then re-build the wheel a second time if I see this right ?
I'm not sure what distros do with wheel packages or how they are made (I see a few wheel packages in openSUSE and Fedora for example, about 5, and they're installed to /usr/lib/python3.someversion/wheels), but yes, the wheel is currently generated in the build dir (build/python/LibraryName/dist/) but not installed as far as I know. From the KDE side, the plan is to publish them to PyPi eventually:tm:.
/usr/lib/python3.someversion/wheels
build/python/LibraryName/dist/
From the KDE side, the plan is to publish them to PyPi eventually.
Is it intended that they also be published to distributions’ repositories?
From the KDE side, the plan is to publish them to PyPi eventually. Is it intended that they also be published to distributions’ repositories?
That would be the goal after they got published at PyPi if your question targets packaging pyside6-kf6 based kde apps written in python like qtpy programs, did you mean that ?
If your question targets packaging pyside6-kf6 based kde apps written in python like qtpy programs, did you mean that ?
@loise, no. I meant whether it'll be installable as a library via distributions’ repositories, as a dependency or otherwise. PyPi is a useful fallback, but as you'll know if you've ever tried to use it for Kirigami libraries, isn't generally suitable as the primary method of distribution.
The packages mentioned in this issue are adding the cpython files necessary for the KDE tutorial, the wheel packages are secondary and don't matter much (to KDE) currently.
@loise, no. I meant whether it'll be installable as a library via distributions’ repositories, as a dependency or otherwise. PyPi is a useful fallback, but as you'll know if you've ever tried to use it for Kirigami libraries, isn't generally suitable as the primary method of distribution. The packages mentioned in this issue are adding the cpython files necessary for the KDE tutorial, the wheel packages are secondary and don't matter much (to KDE) currently.
Did anyone give the KDE tutorial sources a try yet if those work ? Maybe we can make a RPM out of it as a template for packaging pyside6-kf6 apps ?
Metadata Update from @loise: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.