[PyKDE] Multiple PyQt version in one Python installation

[Phil Thompson]

On Sunday 05 November 2006 11:28 am, Simon Edwards wrote:
> On Sunday 05 November 2006 00:29, Phil Thompson wrote:
> > On Saturday 04 November 2006 10:08 pm, Simon Edwards wrote:
> > > sip.so. Point is, once a SIP wrapper for a custom C++ class is compiled
> > > it then depends on that particular version of sip.
> >
> > No it doesn't.
>
> Are you trying to tell me that if I compile a wrapper for a C++ class with
> sip version X, that that little python module for my C++ class, the little
> .so file I mean, doesn't depend on the version of sip used and will work at
> runtime with what ever version of sip the user has installed?
>
> Or am I just not understanding what you are saying. I'm concerned with
> software distributed to users in compiled form.

I'm saying it depends on the SIP API version number, not on the unrelated SIP 
version number.

> > You can't mix two versions of SIP with different API major version
> > numbers. This was last changed to allow PyQt3 and PyQt4 to be installed
> > side by side. I do not anticipate it changing during the life of Qt4 (but
> > I won't make a commitment to that effect).
>
> It is good to hear that it will probably not change. But should it happen,
> will it be possible to install both versions at the same time? like we can
> do with PyQt3 and PyQt4 today?

No. I'm not saying such a thing cannot be done but that the problem doesn't 
merit the effort (and incompatible change) involved.

> Just to make it clearer where I'm coming from, here is the scenario that
> I'm concerned with. Imagine it is a few years down the track, and people
> have been happily developing PyQt applications that also mixing C++
> classes. Debian / Kubuntu / SUSE etc have a lots of these applications
> packaged and in their repositories. Outside the repositories, people have
> also created and distributed software packages. Everyone happy. But then
> sip gets updated and bumps the major version. Will everyone be forced to
> recompile all of the applications if they want to move to the new version
> of sip/PyQt? Or will it be possible to run the older stuff as is, alongside
> the new stuff? Like what we can do with PyQt3 and PyQt4.
>
> Right now it sounds like that on the source code level everything works out
> fine, but for binaries it may not be possible to smoothly transition to a
> new major sip version. This could be a problem for distributions and
> end-users.

I understand where you are coming from, and the situation you describe is 
perfectly possible - and no different from hundreds of other open source 
packages.

For distros it's up to them to make sure they have an internally consistent 
set of compatible binaries.

If you are using out of distro packages you expect to have to recompile them 
from time to time. The most obvious example is if your distro updates it's 
version of Python - you have to recompile your extension modules, whether 
they are SIP based or not.

What I don't get it why SIP merits being singled out for special treatment.

Phil