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
