KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)
jbublitz at nwinternet.com
Tue Sep 12 00:59:06 BST 2006
On Monday 11 September 2006 11:47, Simon Edwards wrote:
> Then if I have a KDE program PyFoo that includes a Python C module (or sip
> wrapper) and was developed for KDE 4.0, it will called something PyFoo2.5
> and require KDE 4.0 or later. When KDE 4.1 comes out maybe Python 2.6 is
> also out, but the packager has also made a python2.5-qt and python2.5-kde
> for KDE 4.1 which is enough to run the older PyFoo2.5 package. This can
> only work if sip and libsip remain backwards compatible during the lifetime
> of KDE4. Although not perfect, there is still a lot of compatibility to be
> had without having to recompile everything everytime a new KDE and Python
> come out.
> To make this possible PyKDE in KDE4 will need to support compiling to
> different target Python versions. Another requirement we need to keep in
> mind for KDE 4.
I guess I don't understand. I'd start from Phil's point - if a new Python rev
isn't binary compatible, then we'd be stuck with some version of Python for
the life of KDE 4., and so would anyone who developed for PyKDE/PyQt. If you
look at what's changed in Python over the life of KDE 3, that doesn't sound
What I don't understand is where the problem occurs - PyKDE will build to
whatever version of Python sip and PyQt were built against, and won't build
against a Python without sip and PyQt. Apps written against those in Python
pretty much will only care if it's Qt/KDE 3 or Qt/KDE 4. Distributors can
tailor their installations so everything works - if some 3rd party bindings
need a specific sip/Python version, there's nothing to prevent that from
co-existing with whatever kdebindings uses, or whatever a user compiles sip,
Anything in KDE should be consistent in the Python version it uses - KDE
already forces lib installs and even new Qt installs with each release. There
is no libsip anymore, as far as I'm concerned - everything is
in /site-packages for a specific Python version. PyKDE already requires sip
later than sip 4.0 (some changes in how mapped type code is written) anyway,
so current versions won't work with libsip/sip3.
So all that's left is some 3rd party apps that depend on sip but aren't part
of KDE and can't be handled by a distributor, and that seems to me to be a
pretty small set to limit ourselves to an obsolete Python version for.
Is there a concrete example of where this is or would be a problem - not
PyFoo, but something real where the problem exists or will exist?
More information about the PyQt