[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: QtPy (python3-qtpy) dependencies



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


Reply to: