I've just uploaded the latest version of QtPy (source: python-qtpy,
binary: python3-qtpy). But I'm disturbed by the dependency list.

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.

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.

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 appreciate thoughts on how to proceed from this group before doing anything.

Best wishes,

Julian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ghis,

On Thu, Apr 07, 2022 at 11:03:22AM +0200, ghisvail@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)