KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)

[Jim Bublitz]

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 
very appealing.

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, 
etc against.

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?

Jim