Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #14047 > unrolled thread

QtPy (python3-qtpy) dependencies

Back to article view | Back to linux.debian.maint.python

Contents

  QtPy (python3-qtpy) dependencies Julian Gilbey <julian@d-and-j.net> - 2022-04-06 23:40 +0200
    Re: QtPy (python3-qtpy) dependencies ghisvail@gmail.com - 2022-04-07 11:10 +0200
      Re: QtPy (python3-qtpy) dependencies Julian Gilbey <julian@d-and-j.net> - 2022-04-07 12:00 +0200
        Re: QtPy (python3-qtpy) dependencies ghisvail@gmail.com - 2022-04-07 12:20 +0200

#14047 — QtPy (python3-qtpy) dependencies

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

[toc] | [next] | [standalone]

#14049

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

[toc] | [prev] | [next] | [standalone]

#14050

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

[toc] | [prev] | [next] | [standalone]

#14051

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web