Re: RFC: New devel project devel:languages:python:pyqt and deal with different SIP versions
Hi, Firstly Cross posting to factory as there is a chance not everyone who needs to read this is on packaging@ (more for packaging help and support) On 2/20/21 6:18 AM, Ben Greiner wrote:
Its worth noting that currently python-qt etc is staged and bought up with each Qt version https://build.opensuse.org/package/show/KDE:Qt:5.15/python-qt5 for example so how well this change will work with the existing Qt setup I guess we will have to wait for the KDE/Qt people to answer.
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Am 21.02.21 um 13:30 schrieb Simon Lees:
In this case the instructions in the project description of devel:languages:python need an update and an appropriate mention of the factory mailing list in the wiki [1] should be added.
It's a long standing myth, but not true [2, 3]. And of course all those subprojects can continue to link to their preferred package version. Strangely, many Qt5 packages in Factory don't even have an assigned devel project at all [4]. python-qt5 has devel project KDE:Qt5, btw.
Cheers, Ben [1] https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory#How_to_request... [2] https://www.riverbankcomputing.com/static/Docs/PyQt5/installation.html#under... [3] https://www.riverbankcomputing.com/static/Docs/PyQt6/installation.html#under... [3] https://build.opensuse.org/project/show/KDE:Qt:5.15#comment-1286381
Am 21.02.21 um 13:30 schrieb Simon Lees:
In this case the instructions in the project description of devel:languages:python need an update and an appropriate mention of the factory mailing list in the wiki [1] should be added. **** ... and of course I hit the send button with the wrong sender tag again, so if a moderator decides to let that through instead of discarding, you get this mail up to 4 times now m-( Sorry. *****
It's a long standing myth, but not true [2, 3]. And of course all those subprojects can continue to link to their preferred package version. Strangely, many Qt5 packages in Factory don't even have an assigned devel project at all [4]. python-qt5 has devel project KDE:Qt5, btw.
Cheers, Ben [1] https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory#How_to_request... [2] https://www.riverbankcomputing.com/static/Docs/PyQt5/installation.html#under... [3] https://www.riverbankcomputing.com/static/Docs/PyQt6/installation.html#under... [3] https://build.opensuse.org/project/show/KDE:Qt:5.15#comment-1286381
On 2/22/21 1:36 AM, Ben Greiner wrote:
Yeah that project description seems wrong, especially now that we have a dedicated python mailing list which can be used for python specific things. But factory is the mailing list where all the developers working on openSUSE in general are so its the best place for questions and discussions that involve multiple parts of the distro. The wiki page already mentions the following, if you have a better wording or can suggest a change let me know and i'm happy to make it. === Whether or not you have edit permissions on the package, you can trigger a submit request of the package to openSUSE:Factory. That submit request should contain a note with information about the package. Preferably, you introduce the package to the opensuse-factory list and point to that introduction in your submitrequest. A good introduction contains information on the state of the upstream project and how maintainable it is and what the purpose of having it in the distribution will be. === -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 22.02.21 00:11, Simon Lees wrote:
The wiki page already mentions the following, if you have a better wording or can suggest a change let me know and i'm happy to make it.
The beauty of a wiki is, that anyone can make the change. But I think the current wording works.
That is for the situation, when you already have the package in a devel project and want to submit to Factory. But we are talking about the situation described right below that paragraph. This proposal is about where to put the packages before forwarding them to Factory. Ben
In data domenica 21 febbraio 2021 13:30:56 CET, Simon Lees ha scritto: Hello,
example so how well this change will work with the existing Qt setup I guess we will have to wait for the KDE/Qt people to answer.
If I understood this correctly, this means a new devel project *exclusively* for PyQt stuff (while official stuff from Qt like PySide would stay there)? If that's the case, at least from me there's a +1, as improved maintenance of PyQt would definitely help. The KDE:Qt projects would just link the packages from Factory in that case. Fabian, Cristophe, are you also OK with this? -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
On 22.02.21 22:03, Luca Beltrame wrote:
If I understood this correctly, this means a new devel project *exclusively* for PyQt stuff (while official stuff from Qt like PySide would stay there)?
I think anything between "just core PyQt/SIP" (the set currently in my ~:pyqt) and "everything to develop for Python and Qt" is imaginable. In the latter case, a more suitable name would be devel:languages:python:qt. It's totally okay if you want to keep PySide[26] in KDE:Qt. QtPy falls somewhere in between the two extremes as it is a wrapper for both PyQt and PySide. And then there are libraries or applications which build heavily on SIP or PyQt, like python-poppler-qt, qutebrowser, or eric. The first two have a good home at their existing devel projects. The latter is in the catchall d:l:p, and I am sure both Matej and Pete would be happy to move it to a sub project. Ben
Dear Ben, Am Montag, 22. Februar 2021, 22:54:44 CET schrieb Ben Greiner:
Sorry for the late reply. Something called "life" strongly distracts me from being a responsive citizen for the community at the moment. The only issue I see at the moment, is how to support multiple Qt versions besides the default one, that comes with the distribution. Since the development targets of PyQt and PySide are pretty diverging (the former is able to support nearly any combination in the Qt and PyQt version matrix, while the latter is pretty strongly bound to Qt development itself). So yes, d:l:py:pyqt for the former and keep the latter side by side with the Qt build itself does make the most sense to me. Hermaphrodite projects like QtPy will never fit frictionless anyway. OTOH, any activity, that consolidates the state and manageability of these packages is much appreciated, because of the development shift in SIP 4..6. Thanks for your continuous effort to improve the status quo. Pete
Dne 06/03/2021 v 03:25 Hans-Peter Jansen napsal(a):
OTOH, any activity, that consolidates the state and manageability of these packages is much appreciated, because of the development shift in SIP 4..6.
Let me just add my 0.02 ¢: I am not sure about the scholastic distinctions between PyQt and PySide, but I found really weird, when we have GUI-related (both Gnome and Qt/KDE/whatever) packages in d:l:p itself. I have just tried to kick python-GooCalendar out of d:l:p to the Gnome-land, because these packages are really not that much about Python, and they are more about the underlying GUI, and I have absolutely no clue about that. Concerning the name and the organization: why not to call it PyKDE as all-covering project? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 You either die a hero or you live long enough to see yourself become the villain. -- Harvey Dent in The Dark Knight
Hi, Am 06.03.21 um 10:29 schrieb Matěj Cepl:
The biggest motivation for my proposal is the counterpoint to this: Most apps building on PyQt are very python centristic. Naturally, you already find many of them in d:l:p. The packaging has to cater to all of the python specific stuff (e.g. singlespec). There is no direct interface to the Qt libraries. They are not in KDE:*, because they are not connected to the KDE or Qt upstream projects other than using their libraries through PyQt and SIP. The PyQt family itself is a separate upstream project. Phil Thompson's Riverbank Computing is not related to KDE or Qt. Building PyPI hosted SIP, PyQt[56], PyQt{,6}-*, and QScintilla requires python packaging skills. And please let me repeat, because this is often misunderstood: PyQt5 packages build against any Qt5 version and the PyQt6 packages build against Qt6. The infamous %Timeline SIP directive makes sure to support only features present in a specific Qt version: Building PyQt5 5.15.3 from source against Qt 5.12 works. It just does not contain the features introduced since then. We already agree that PySide, coming directly from Qt, should remain with the KDE:Qt devel projects. We also agree that packages should be moved from d:l:p to more specific (sub)projects. IMHO devel:language:python:pyqt is the most fitting place in the devel project taxonomy. PyQt is not furhter away from developing python related software than NumPy in d:l:p:numeric, Jupyter, or Django.
Concerning the name and the organization: why not to call it PyKDE as all-covering project?
These packages use Qt as GUI toolkit, but there is really no further connection to KDE at all.
Matěj
Ben
On 3/6/21 10:29 AM, Matěj Cepl wrote:
From my understand devel:languages:python is for all module packages you might need to develop Python programs. Thus I'd certainly expect to find also all module packages for GUI programming therein. Splitting everything apart does not help solving any problem. Ciao, Michael.
On 3/6/21 8:48 PM, Michael Ströder wrote:
This is not entirely true, python libraries that are generally just a wrapper around some other library or tool have always tended to sit with said tool because its generally much easier for maintainers, for example python-dbus-python is in Base:System and python-efl is in X11:Enlightenment:Factory with efl and the apps that use it. Taking python-efl as an example if it was in d:l:p I would have to 1 submit efl to factory, wait for it to be accepted then 2 update python-efl in d:l:p then 3 come back and update any python-efl updates that broke. With python-efl in the same place as the gui toolkit and applications I can just do it all in one submission. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Dne 06. 03. 21 v 11:18 Michael Ströder napsal(a):
I hate to say it to you, but then your understanding of d:l:p is not correct. We repeatedly asked people to keep particularly Python bindings to GUI libraries (and their friends) in their particular projects, because for maintenance of those packages are more important specialized packages, which are more located among maintainers of the particular GUI projects than we with us general Python packagers. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 http://xkcd.com/743/ … enough said.
Am 21.02.21 um 13:30 schrieb Simon Lees:
In this case the instructions in the project description of devel:languages:python need an update and an appropriate mention of the factory mailing list in the wiki [1] should be added.
It's a long standing myth, but not true [2, 3]. And of course all those subprojects can continue to link to their preferred package version. Strangely, many Qt5 packages in Factory don't even have an assigned devel project at all [4]. python-qt5 has devel project KDE:Qt5, btw.
Cheers, Ben [1] https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory#How_to_request... [2] https://www.riverbankcomputing.com/static/Docs/PyQt5/installation.html#under... [3] https://www.riverbankcomputing.com/static/Docs/PyQt6/installation.html#under... [3] https://build.opensuse.org/project/show/KDE:Qt:5.15#comment-1286381
Am 21.02.21 um 13:30 schrieb Simon Lees:
In this case the instructions in the project description of devel:languages:python need an update and an appropriate mention of the factory mailing list in the wiki [1] should be added. **** ... and of course I hit the send button with the wrong sender tag again, so if a moderator decides to let that through instead of discarding, you get this mail up to 4 times now m-( Sorry. *****
It's a long standing myth, but not true [2, 3]. And of course all those subprojects can continue to link to their preferred package version. Strangely, many Qt5 packages in Factory don't even have an assigned devel project at all [4]. python-qt5 has devel project KDE:Qt5, btw.
Cheers, Ben [1] https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory#How_to_request... [2] https://www.riverbankcomputing.com/static/Docs/PyQt5/installation.html#under... [3] https://www.riverbankcomputing.com/static/Docs/PyQt6/installation.html#under... [3] https://build.opensuse.org/project/show/KDE:Qt:5.15#comment-1286381
On 2/22/21 1:36 AM, Ben Greiner wrote:
Yeah that project description seems wrong, especially now that we have a dedicated python mailing list which can be used for python specific things. But factory is the mailing list where all the developers working on openSUSE in general are so its the best place for questions and discussions that involve multiple parts of the distro. The wiki page already mentions the following, if you have a better wording or can suggest a change let me know and i'm happy to make it. === Whether or not you have edit permissions on the package, you can trigger a submit request of the package to openSUSE:Factory. That submit request should contain a note with information about the package. Preferably, you introduce the package to the opensuse-factory list and point to that introduction in your submitrequest. A good introduction contains information on the state of the upstream project and how maintainable it is and what the purpose of having it in the distribution will be. === -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 22.02.21 00:11, Simon Lees wrote:
The wiki page already mentions the following, if you have a better wording or can suggest a change let me know and i'm happy to make it.
The beauty of a wiki is, that anyone can make the change. But I think the current wording works.
That is for the situation, when you already have the package in a devel project and want to submit to Factory. But we are talking about the situation described right below that paragraph. This proposal is about where to put the packages before forwarding them to Factory. Ben
In data domenica 21 febbraio 2021 13:30:56 CET, Simon Lees ha scritto: Hello,
example so how well this change will work with the existing Qt setup I guess we will have to wait for the KDE/Qt people to answer.
If I understood this correctly, this means a new devel project *exclusively* for PyQt stuff (while official stuff from Qt like PySide would stay there)? If that's the case, at least from me there's a +1, as improved maintenance of PyQt would definitely help. The KDE:Qt projects would just link the packages from Factory in that case. Fabian, Cristophe, are you also OK with this? -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
On 22.02.21 22:03, Luca Beltrame wrote:
If I understood this correctly, this means a new devel project *exclusively* for PyQt stuff (while official stuff from Qt like PySide would stay there)?
I think anything between "just core PyQt/SIP" (the set currently in my ~:pyqt) and "everything to develop for Python and Qt" is imaginable. In the latter case, a more suitable name would be devel:languages:python:qt. It's totally okay if you want to keep PySide[26] in KDE:Qt. QtPy falls somewhere in between the two extremes as it is a wrapper for both PyQt and PySide. And then there are libraries or applications which build heavily on SIP or PyQt, like python-poppler-qt, qutebrowser, or eric. The first two have a good home at their existing devel projects. The latter is in the catchall d:l:p, and I am sure both Matej and Pete would be happy to move it to a sub project. Ben
Dear Ben, Am Montag, 22. Februar 2021, 22:54:44 CET schrieb Ben Greiner:
Sorry for the late reply. Something called "life" strongly distracts me from being a responsive citizen for the community at the moment. The only issue I see at the moment, is how to support multiple Qt versions besides the default one, that comes with the distribution. Since the development targets of PyQt and PySide are pretty diverging (the former is able to support nearly any combination in the Qt and PyQt version matrix, while the latter is pretty strongly bound to Qt development itself). So yes, d:l:py:pyqt for the former and keep the latter side by side with the Qt build itself does make the most sense to me. Hermaphrodite projects like QtPy will never fit frictionless anyway. OTOH, any activity, that consolidates the state and manageability of these packages is much appreciated, because of the development shift in SIP 4..6. Thanks for your continuous effort to improve the status quo. Pete
Dne 06/03/2021 v 03:25 Hans-Peter Jansen napsal(a):
OTOH, any activity, that consolidates the state and manageability of these packages is much appreciated, because of the development shift in SIP 4..6.
Let me just add my 0.02 ¢: I am not sure about the scholastic distinctions between PyQt and PySide, but I found really weird, when we have GUI-related (both Gnome and Qt/KDE/whatever) packages in d:l:p itself. I have just tried to kick python-GooCalendar out of d:l:p to the Gnome-land, because these packages are really not that much about Python, and they are more about the underlying GUI, and I have absolutely no clue about that. Concerning the name and the organization: why not to call it PyKDE as all-covering project? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 You either die a hero or you live long enough to see yourself become the villain. -- Harvey Dent in The Dark Knight
Hi, Am 06.03.21 um 10:29 schrieb Matěj Cepl:
The biggest motivation for my proposal is the counterpoint to this: Most apps building on PyQt are very python centristic. Naturally, you already find many of them in d:l:p. The packaging has to cater to all of the python specific stuff (e.g. singlespec). There is no direct interface to the Qt libraries. They are not in KDE:*, because they are not connected to the KDE or Qt upstream projects other than using their libraries through PyQt and SIP. The PyQt family itself is a separate upstream project. Phil Thompson's Riverbank Computing is not related to KDE or Qt. Building PyPI hosted SIP, PyQt[56], PyQt{,6}-*, and QScintilla requires python packaging skills. And please let me repeat, because this is often misunderstood: PyQt5 packages build against any Qt5 version and the PyQt6 packages build against Qt6. The infamous %Timeline SIP directive makes sure to support only features present in a specific Qt version: Building PyQt5 5.15.3 from source against Qt 5.12 works. It just does not contain the features introduced since then. We already agree that PySide, coming directly from Qt, should remain with the KDE:Qt devel projects. We also agree that packages should be moved from d:l:p to more specific (sub)projects. IMHO devel:language:python:pyqt is the most fitting place in the devel project taxonomy. PyQt is not furhter away from developing python related software than NumPy in d:l:p:numeric, Jupyter, or Django.
Concerning the name and the organization: why not to call it PyKDE as all-covering project?
These packages use Qt as GUI toolkit, but there is really no further connection to KDE at all.
Matěj
Ben
On 3/6/21 10:29 AM, Matěj Cepl wrote:
From my understand devel:languages:python is for all module packages you might need to develop Python programs. Thus I'd certainly expect to find also all module packages for GUI programming therein. Splitting everything apart does not help solving any problem. Ciao, Michael.
On 3/6/21 8:48 PM, Michael Ströder wrote:
This is not entirely true, python libraries that are generally just a wrapper around some other library or tool have always tended to sit with said tool because its generally much easier for maintainers, for example python-dbus-python is in Base:System and python-efl is in X11:Enlightenment:Factory with efl and the apps that use it. Taking python-efl as an example if it was in d:l:p I would have to 1 submit efl to factory, wait for it to be accepted then 2 update python-efl in d:l:p then 3 come back and update any python-efl updates that broke. With python-efl in the same place as the gui toolkit and applications I can just do it all in one submission. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Dne 06. 03. 21 v 11:18 Michael Ströder napsal(a):
I hate to say it to you, but then your understanding of d:l:p is not correct. We repeatedly asked people to keep particularly Python bindings to GUI libraries (and their friends) in their particular projects, because for maintenance of those packages are more important specialized packages, which are more located among maintainers of the particular GUI projects than we with us general Python packagers. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 http://xkcd.com/743/ … enough said.
participants (7)
-
Ben Greiner -
Benjamin Greiner -
Hans-Peter Jansen -
Luca Beltrame -
Matěj Cepl -
Michael Ströder -
Simon Lees