Convert dephell and bowler ITPs to RFPs
submitter 962574 ! retitle 962574 RFP: dephell -- project management for Python noowner 962574 submitter 941054 ! retitle 941054 RFP: python-bowler -- safe code refactoring for modern Python projects noowner 941054 thanks I have not found the time to make meaningful progress on Dephell and its dependency Bowler, so am converting these ITPs to RFPs. Please feel free to take them over. Best, Nicholas signature.asc Description: PGP signature
Re: python3-pysnmp4 forked upstream
On 4/7/22 17:22, Stefano Rivera wrote: > > Sounds like switching to the fork is a good idea. Then I will have a go at it tomorrow. Thanks for the input. Luiz
Re: python3-pysnmp4 forked upstream
Hi Luiz (2022.04.07_11:22:49_+) > It looks like the current upstream[1] of pysnmp has been unmaintained > for a while and got forked [2]. > > FreeBSD has done some adjustments to pysnmp and the related packages > because of that [3][4], as the current version seems broken in Python 3.9. > > What is your opinion on updating these packages to use the forked upstream? Sounds like switching to the fork is a good idea. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1009131: RFP: python-arabic-reshaper -- Reconstruct Arabic sentences to be used in applications that don't support Arabic script.
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org Control: affects -1 src:xhtml2pdf * Package name: python-arabic-reshaper Version : 2.1.3 Upstream Author : Abdullah Diab * URL : https://github.com/mpcabd/python-arabic-reshaper/ * License : MIT Programming Lang: Python Description : Reconstruct Arabic sentences to be used in applications that don't support Arabic script. Arabic script is very special with two essential features: 1. It is written from right to left. 2. The characters change shape according to their surrounding characters. So when you try to print text written in Arabic script in an application – or a library – that doesn’t support Arabic you’re pretty likely to end up with misformatted text. There are two problems. First, the characters are in the isolated form, which means that every character is rendered regardless of its surroundings, and second is that the text is written from left to right. To solve the latter issue all we have to do is to use the Unicode bidirectional algorithm, which is implemented purely in Python in python-bidi. The only issue left to solve is to reshape those characters and replace them with their correct shapes according to their surroundings. Using this library helps with the reshaping so we can get the proper result. python-arabic-reshaper will be used by xhtml2pdf. python-arabic-reshaper should be maintained by the Python Module Team alongside python-bidi (RFP#921336)
Re: python3-pysnmp4 forked upstream
On Thu, Apr 07, 2022 at 01:22:49PM +0200, Luiz Amaral wrote: > Hello Python Team, > > It looks like the current upstream[1] of pysnmp has been unmaintained > for a while and got forked [2]. > > FreeBSD has done some adjustments to pysnmp and the related packages > because of that [3][4], as the current version seems broken in Python 3.9. > > What is your opinion on updating these packages to use the forked upstream? > > I cced Julien specifically because I saw he was working on pyasn1 > yesterday. > Hi Luiz, Sorry, I've got no knowledge of / interest in pysnmp at the moment. (I only did a drive-by upload of pyasn1-modules yesterday because I was looking at RFC3161 and that was missing in the version in sid.) Cheers, Julien
python3-pysnmp4 forked upstream
Hello Python Team, It looks like the current upstream[1] of pysnmp has been unmaintained for a while and got forked [2]. FreeBSD has done some adjustments to pysnmp and the related packages because of that [3][4], as the current version seems broken in Python 3.9. What is your opinion on updating these packages to use the forked upstream? I cced Julien specifically because I saw he was working on pyasn1 yesterday. Thank you, Luiz. [1] https://github.com/etingof/pysnmp [2] https://github.com/pysnmp/pysnmp [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257860 [4] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262906
Re: QtPy (python3-qtpy) dependencies
Le jeudi 07 avril 2022 à 10:49 +0100, Julian Gilbey a écrit :
> > > At present, the Debian python3-qtpy package depends on 17
> > > python3-pyqt5* packages, which seems to be at odds with the
> > > intention
> > > of the package to be Qt-package agnostic. It seems that it would
> > > be
> > > cleaner for python3-qtpy to
> > > Recommends: python3-pyqt5 | python3-pyside2.qtcore
> > > or perhaps to Depends: on these, and then if any packages require
> > > any
> > > more functionality than that provided by python3-pyqt5 or
> > > python3-pyside2.qtcore, they should explicitly state the packages
> > > they
> > > depend on. But it seems strange that a package depending on
> > > python3-qtpy should automatically pull in
> > > python3-pyqt5.qttexttospeech, for example.
> >
> > Agreed. I suppose the PyQt5 ecosystem has grown since initial
> > submission. There are two issues here: hard or soft depends and to
> > which core packages.
> >
> > Regarding Depends vs Recommends, as you correctly stated before,
> > QtPy
> > is useless without a "backend" implementation. Which is why I chose
> > Depends with a choice of alternatives. This way, a client package
> > depending on QtPy would always get a default implementation, whilst
> > having the possibility to override it with its own (but then what's
> > the
> > point?).
>
> That makes a lot of sense as well. At present, it still seems that
> PyQt5 is the most standard, but I don't have much of evidence to back
> up that hunch.
The stats for PyPI downloads backs that up:
https://libraries.io/pypi/PyQt5
https://libraries.io/pypi/PySide2
I have a feeling this will turn differently for PyQt6 vs PySide6.
> > Regarding which packages to depend on, that's subject to which
> > subset
> > of Qt{5,6} is supported by QtPy today. These might be in a need for
> > an
> > update.
>
> It appears that PyQt6 isn't in Debian yet, so that's not really an
> option. Neither is PySide6, so it's just PyQt5 or PySide2.
>
In that case, there is not much else to do. Same status quo as last
time I contributed to the package.
> > > On the other hand, there are 13 packages in testing that depend
> > > on
> > > python3-qtpy, so they would potentially all require modifications
> > > to
> > > their dependencies if we made this change. (Three of these are
> > > "mine", but that still leaves 10 that are not.) I have not yet
> > > gone
> > > through all 13 to see what python3-pyqt5.* dependencies they
> > > actually
> > > have.
> >
> > I'd be in favour with the least invasive option, which is to still
> > use
> > QtPy with Depends on a default implementation but update it with
> > what's
> > available today.
>
> I'm happy with sticking with that. I still think we have too many
> dependencies, though; it's become rather a metapackage for PyQt5!
> But
> it's not a big deal.
That's the danger with these shim packages. If they don't capture the
same granularity of components as the backend implementations it wraps,
then it becomes a rather heavy and annoying metapackage.
Hope this helps.
Ghis
Re: QtPy (python3-qtpy) dependencies
Hi Ghis,
On Thu, Apr 07, 2022 at 11:03:22AM +0200, ghisv...@gmail.com wrote:
> Hi Julian,
>
> Le mercredi 06 avril 2022 à 22:01 +0100, Julian Gilbey a écrit :
> > I've just uploaded the latest version of QtPy (source: python-qtpy,
> > binary: python3-qtpy). But I'm disturbed by the dependency list.
>
> Thank you for taking care of it.
Pleasure; I needed it for the latest version of Spyder, but it's
turning out to be a little harder than I anticipated!
> > QtPy is a wrapper for PyQt5, PyQt6, PySide2 and PySide6 providing a
> > uniform interface to these different packages. As such, setup.py
> > etc. do not specify a dependency on any Qt library, but the package
> > is
> > of no use without at least one of them installed.
>
> You analysis is correct.
>
> I'll add that, at the time of the initial package submission, only
> PyQt5 and PySide2 were supported and the latter was in an uncertain
> state maintenance-wise. So it serves pretty much as a shim layer for
> "some wrapper around modern Qt" but the only viable option was PyQt5.
>
> Hopefully, things are completely different now and the alternatives
> have caught up. Which I guess is the origin of your struggle today.
That makes a lot of sense!
> > At present, the Debian python3-qtpy package depends on 17
> > python3-pyqt5* packages, which seems to be at odds with the intention
> > of the package to be Qt-package agnostic. It seems that it would be
> > cleaner for python3-qtpy to
> > Recommends: python3-pyqt5 | python3-pyside2.qtcore
> > or perhaps to Depends: on these, and then if any packages require any
> > more functionality than that provided by python3-pyqt5 or
> > python3-pyside2.qtcore, they should explicitly state the packages
> > they
> > depend on. But it seems strange that a package depending on
> > python3-qtpy should automatically pull in
> > python3-pyqt5.qttexttospeech, for example.
>
> Agreed. I suppose the PyQt5 ecosystem has grown since initial
> submission. There are two issues here: hard or soft depends and to
> which core packages.
>
> Regarding Depends vs Recommends, as you correctly stated before, QtPy
> is useless without a "backend" implementation. Which is why I chose
> Depends with a choice of alternatives. This way, a client package
> depending on QtPy would always get a default implementation, whilst
> having the possibility to override it with its own (but then what's the
> point?).
That makes a lot of sense as well. At present, it still seems that
PyQt5 is the most standard, but I don't have much of evidence to back
up that hunch.
> Regarding which packages to depend on, that's subject to which subset
> of Qt{5,6} is supported by QtPy today. These might be in a need for an
> update.
It appears that PyQt6 isn't in Debian yet, so that's not really an
option. Neither is PySide6, so it's just PyQt5 or PySide2.
> > On the other hand, there are 13 packages in testing that depend on
> > python3-qtpy, so they would potentially all require modifications to
> > their dependencies if we made this change. (Three of these are
> > "mine", but that still leaves 10 that are not.) I have not yet gone
> > through all 13 to see what python3-pyqt5.* dependencies they actually
> > have.
>
> I'd be in favour with the least invasive option, which is to still use
> QtPy with Depends on a default implementation but update it with what's
> available today.
I'm happy with sticking with that. I still think we have too many
dependencies, though; it's become rather a metapackage for PyQt5! But
it's not a big deal.
> > I'd appreciate thoughts on how to proceed from this group before
> > doing
> > anything.
>
> Good luck.
>
> Cheers,
> Ghis
Thanks!
Julian
Re: QtPy (python3-qtpy) dependencies
Hi Julian,
Le mercredi 06 avril 2022 à 22:01 +0100, Julian Gilbey a écrit :
> I've just uploaded the latest version of QtPy (source: python-qtpy,
> binary: python3-qtpy). But I'm disturbed by the dependency list.
Thank you for taking care of it.
> QtPy is a wrapper for PyQt5, PyQt6, PySide2 and PySide6 providing a
> uniform interface to these different packages. As such, setup.py
> etc. do not specify a dependency on any Qt library, but the package
> is
> of no use without at least one of them installed.
You analysis is correct.
I'll add that, at the time of the initial package submission, only
PyQt5 and PySide2 were supported and the latter was in an uncertain
state maintenance-wise. So it serves pretty much as a shim layer for
"some wrapper around modern Qt" but the only viable option was PyQt5.
Hopefully, things are completely different now and the alternatives
have caught up. Which I guess is the origin of your struggle today.
> At present, the Debian python3-qtpy package depends on 17
> python3-pyqt5* packages, which seems to be at odds with the intention
> of the package to be Qt-package agnostic. It seems that it would be
> cleaner for python3-qtpy to
> Recommends: python3-pyqt5 | python3-pyside2.qtcore
> or perhaps to Depends: on these, and then if any packages require any
> more functionality than that provided by python3-pyqt5 or
> python3-pyside2.qtcore, they should explicitly state the packages
> they
> depend on. But it seems strange that a package depending on
> python3-qtpy should automatically pull in
> python3-pyqt5.qttexttospeech, for example.
Agreed. I suppose the PyQt5 ecosystem has grown since initial
submission. There are two issues here: hard or soft depends and to
which core packages.
Regarding Depends vs Recommends, as you correctly stated before, QtPy
is useless without a "backend" implementation. Which is why I chose
Depends with a choice of alternatives. This way, a client package
depending on QtPy would always get a default implementation, whilst
having the possibility to override it with its own (but then what's the
point?).
Regarding which packages to depend on, that's subject to which subset
of Qt{5,6} is supported by QtPy today. These might be in a need for an
update.
> On the other hand, there are 13 packages in testing that depend on
> python3-qtpy, so they would potentially all require modifications to
> their dependencies if we made this change. (Three of these are
> "mine", but that still leaves 10 that are not.) I have not yet gone
> through all 13 to see what python3-pyqt5.* dependencies they actually
> have.
I'd be in favour with the least invasive option, which is to still use
QtPy with Depends on a default implementation but update it with what's
available today.
> I'd appreciate thoughts on how to proceed from this group before
> doing
> anything.
Good luck.
Cheers,
Ghis
PyQt5 question: why are QOpenGLTimeMonitor/QOpenGLTimerQuery not defined on armhf?
Well, the new version of qtpy failed the CI checks on armhf, and I
don't understand why. The cause is that the following caused an
error:
(sid_armhf-dchroot)jdg@abel:~$ python3
Python 3.10.4 (main, Apr 2 2022, 09:04:19) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyQt5.QtGui import QOpenGLTimeMonitor
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name 'QOpenGLTimeMonitor' from 'PyQt5.QtGui'
(/usr/lib/python3/dist-packages/PyQt5/QtGui.abi3.so)
>>> from PyQt5.QtGui import QOpenGLTimerQuery
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name 'QOpenGLTimerQuery' from 'PyQt5.QtGui'
(/usr/lib/python3/dist-packages/PyQt5/QtGui.abi3.so)
Why are these two classes not defined on armhf? I had a quick look at
the source code for PyQt5, and I see the following:
sip/QtGui/qopengltimerquery.sip, lines 23-:
%If (Qt_5_1_0 -)
%If (PyQt_Desktop_OpenGL)
class QOpenGLTimerQuery : QObject
{
%TypeHeaderCode
#include
%End
[...]
So I presume that if PyQt_Desktop_OpenGL is defined, then this is
included. This would be set in config-tests/cfgtest_QtGui.cpp, lines
28-:
#if defined(QT_NO_OPENGL)
out << "PyQt_OpenGL\n";
out << "PyQt_Desktop_OpenGL\n";
#elif defined(QT_OPENGL_ES) || defined(QT_OPENGL_ES_2) ||
defined(QT_OPENGL_ES_3)
out << "PyQt_Desktop_OpenGL\n";
#endif
But nowhere do I find any of QT_NO_OPENGL or QT_OPENGL_ES* defined in
the package (but then maybe I'm not looking in the right place? So I
don't know why these two classes are included in the amd64 version of
the package but not the armhf version.
I could just protect the two imports with a try/except block, but I
would like to know that this is the right thing to do first!
Thanks,
Julian
