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

[Phil Thompson]

> On Tuesday 12 September 2006 01:59, Jim Bublitz wrote:
>> 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.
>
> The important piece of information that you need is that distributions can
> and
> do ship *multiple* Python versions in the same release (and Debian does).
> This includes multiple versions of the same binary python modules,
> compilied
> for the different Python versions that they want to support. By supporting
> installation of multiple Python versions on the same computer,
> distributions
> can offer better backwards compatibility and phase in support for a new
> Python version while gently phasing out support for older versions. This
> saves distros from having to recompile everything all at once when moving
> to
> a new Python version, and allows other 3rd party packages to continue
> working
> without modification or recompile. Remember that not all of the packages
> that
> run on a given distro are created and managed by that distro.
>
>> 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.
>
> Consider this example. KDE 4.0 comes out with PyKDE included. PyKDE in KDE
> 4.0
> uses sip 4. This is all packaged by Debian along with python into these
> packages:
>
> 	python2.5 (version 2.5.0 of Python)
> 	kdelibs (version 4.0 of KDE)
> 	python2.5-kde (version 4.0 of PyKDE, contains the sip4 library)
> 	PyFoo2.5
>
> "2.5" is included in the name of these packages because these packages
> only
> work with Python 2.5. PyFoo is also specifically compilied for Python 2.5.
>
> A developer writes PyFoo, a KDE app in python which also includes a C++
> part
> which users and depends on sip 4. The package is called PyFoo2.5 and
> depends
> on package python2.5-kde.
>
> Later Python 2.6 and KDE 4.1 comes out. The distro creates new packages of
> Python 2.6 and KDE, and also keeps python 2.5 around for compatibility.
> The
> list of packages looks like this:
>
> 	python2.5 (version 2.5 of Python)
> 	python2.6 (version 2.6 of Python)
> 	python2.5-kde (new version 4.1 of PyKDE, compilied for Python 2.5)
> 	python2.6-kde (new version 4.1 of PyKDE, compilied for Python 2.6)
>
> Python 2.5 and 2.6 are both now happily supported. Python's poor module
> ABI
> compatibility is handled.
>
> Now the problem is the old PyFoo package. It depends on python2.5-kde
> version
> 4.0 or better and hence sip 4, because sip 4 is what shipped in KDE 4.0.
> This
> is the version of sip that PyFoo runs on. If the new python2.5-kde package
> for KDE 4.1 includes a different and incompatible version of sip (say sip
> 5),
> then the PyFoo2.5 will not work.
>
>> 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.
>
> Yes, KDE may force the installation of newer libraries. But the policy is
> that
> stuff that runs on an older KDE will still run on a newer KDE. (in the
> same
> series of course). Newer versions of libraries still run software which
> was
> build for the older version.
>
> Am I having any sucess in explaining why PyKDE in KDE4 will need to
> maintain
> backwards compatible sip versions during the lifetime of KDE4?

Yes, given what you have described. The risk is that a future Qt v4.n
includes a new module that needs a non-binary compatible SIP change to
support properly. I can't think what might trigger such an incompatible
change - but you never know.

Checking back, the last incompatible change was with SIP v4.3 in August
2005. This was triggered by the desire to have PyQt3 and PyQt4 installed
side by side using the same copy of the sip module.

One thing you need to check is that you can install kdebindings3 (ie.
PyQt3 using SIP3) and kdebindings4 (ie. PyQt4 using SIP4) in the same
Python installation. I assume this is a requirement - so that people can
continue to use PyKDE3 applications not yet ported to PyKDE4 while running
KDE4 as their desktop. This is not something I test - SIP3 has been
unsupported for a long time.

Phil