Re: [PyKDE] Multiple PyQt version in one Python installation
On Monday 06 November 2006 08:18, Andreas Pakulat wrote: On 05.11.06 19:20:00, Simon Edwards wrote: I don't think that is quite the case. The standard approach that distributions use for this kind of problem is to make it possible to install the old version along side the new one. This is very common for shared libraries for example. And they also re-compile their apps against the newer version as soon as possible, so they can obsolete the old version and drop it. Because maintaining 2 or more versions of the same lib is a nightmare. True. But as a user I can still install the new version along side the old one. 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. I am fairly sure that that is not how Debian handles Python these days. Actually it is. but the old ones keep working. That's the point. Well, different Python versions and especially their extension modules are installed into totally different prefixes. Lets say SIP version X is coming out and uncompatible with version Y (XY) then Debians python maintainers do one of two things: a) Prepare a new upload of sip (version X) to unstable, upload it and when it hits unstable recompile all the dependant modules, which currently is PyQt3/4 and PyKDE - AFAIK That's the trick. Right now the list of dependant modules is very short and manageable and doesn't form a big problem. I'm thinking about the future where this list may be much longer and no longer manageable. This is no different than an upgrade of libstdc++ would work, if they change their ABI or even API. You can't install 2 versions of that either, because as soon as the basic libs (like Qt for Qt/KDE/PyKDE/PyQt apps) compile against it your applications will break and you have to recompile everything. libstdc++ is a different case since it depends on so much stuff it is not practical to produce separate packages for applications that are compiled against different libstdc++ versions. This is different than the situation for Python modules. They are packaged in separate packages which can be installed in parallel (e.g. python2.4-ldap and python2.5-ldap). Mind you, looking in the package manager right now I can see 5 different versions of libstdc++ that I can install if need be. And when you compare the situation of PyQt3/PyQt4 to that of old/new sip version your comparing apples and pears. The proper comparison would be between 2 different versions of PyQt4, which cannot be installed together and you might have a similar problem there. I _am_ talking about installing two different versions of PyQt. One compiled on sip API X and another with sip API X+1. I would like that to work as smoothly as PyQt3 and PyQt4. I guess that at the end of the day it is not a urgent problem today. There are very few applications that use SIP, and if a developer needs to use optimise something they can use C and maybe the new 'ctypes' module in Python 2.5. This problem is something which developers and packagers need keep in the back of their mind so to speak. Also if sip API versions become a problem for a distro, they could still combine a move to a new sip API version with a new Python version. I mean, have PyQt4 + sip API version X for Python 2.5, and but then for Python 2.6 compile PyQt4 with sip API X+1. They would work out too. Python versions do come out regularly. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
On 06.11.06 21:01:59, Simon Edwards wrote: On Monday 06 November 2006 08:18, Andreas Pakulat wrote: On 05.11.06 19:20:00, Simon Edwards wrote: This is no different than an upgrade of libstdc++ would work, if they change their ABI or even API. You can't install 2 versions of that either, because as soon as the basic libs (like Qt for Qt/KDE/PyKDE/PyQt apps) compile against it your applications will break and you have to recompile everything. libstdc++ is a different case since it depends on so much stuff it is not practical to produce separate packages for applications that are compiled against different libstdc++ versions. Actually there are multiple libstdc++ in Debian, its just that the libaries and apps that depend on it all depend on the same version (except during the transition time). This is different than the situation for Python modules. They are packaged in separate packages which can be installed in parallel (e.g. python2.4-ldap and python2.5-ldap). Thats wrong, at least for Debian. They provide only python-ldap. Mind you, looking in the package manager right now I can see 5 different versions of libstdc++ that I can install if need be. Right. And when you compare the situation of PyQt3/PyQt4 to that of old/new sip version your comparing apples and pears. The proper comparison would be between 2 different versions of PyQt4, which cannot be installed together and you might have a similar problem there. I _am_ talking about installing two different versions of PyQt. One compiled on sip API X and another with sip API X+1. I would like that to work as smoothly as PyQt3 and PyQt4. Well, David has proposed something to install sip as python egg... Anyway I think I wasn't quite yet awake this morning. I can totally agree with you that in cases where sip changes API or ABI compatibility it would be nice to install new and old version side-by-side for easier transition. Andreas -- Your goose is cooked. (Your current chick is burned up too!) ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
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. 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? 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. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
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 ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
Andreas Pakulat wrote: I think the most problematic part for getting PyQt as egg is integrating the PyQt buildsystem (and sips probably too) into the setuptools. I have posted to this list an incomplete setup.py for building and installing SIP. It was built atop of distutils, but it could be simplified with setuptools and completed. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
On Sunday 05 November 2006 13:15, Phil Thompson wrote: 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. I don't think that is quite the case. The standard approach that distributions use for this kind of problem is to make it possible to install the old version along side the new one. This is very common for shared libraries for example. 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. I am fairly sure that that is not how Debian handles Python these days. They phase in support for newer Python versions and modules, while maintaining the older packages for any software that needs them. Right I use Python 2.4 and I can also install packages for 2.3 or 2.5, and use the them at the same time. What I don't get it why SIP merits being singled out for special treatment. The parallel installation trick doesn't work for SIP inside the same Python version. The reason why I'm busying myself with this whole issue is because KDE 4 is coming and little has been communicated about Python and PyKDE in the KDE community. I've been talking to Jim about his plans for PyKDE, and once I've got some of the details worked out I'll be promoting PyKDE a bit to the KDE core developers and anyone else who will listen. :-) cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
On 05.11.06 19:20:00, Simon Edwards wrote: On Sunday 05 November 2006 13:15, Phil Thompson wrote: 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. I don't think that is quite the case. The standard approach that distributions use for this kind of problem is to make it possible to install the old version along side the new one. This is very common for shared libraries for example. And they also re-compile their apps against the newer version as soon as possible, so they can obsolete the old version and drop it. Because maintaining 2 or more versions of the same lib is a nightmare. 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. I am fairly sure that that is not how Debian handles Python these days. Actually it is. They phase in support for newer Python versions and modules, while maintaining the older packages for any software that needs them. Right I use Python 2.4 and I can also install packages for 2.3 or 2.5, and use the them at the same time. Well, different Python versions and especially their extension modules are installed into totally different prefixes. Lets say SIP version X is coming out and uncompatible with version Y (XY) then Debians python maintainers do one of two things: a) Prepare a new upload of sip (version X) to unstable, upload it and when it hits unstable recompile all the dependant modules, which currently is PyQt3/4 and PyKDE - AFAIK b) Prepare an upload for experimental and also upload new PyQt/PyKDE/Whatever packages for experimental too. This is no different than an upgrade of libstdc++ would work, if they change their ABI or even API. You can't install 2 versions of that either, because as soon as the basic libs (like Qt for Qt/KDE/PyKDE/PyQt apps) compile against it your applications will break and you have to recompile everything. But these things are well prepared in Debian in general and they work really smooth, except for those unstable-users that are unfamiliar and shouldn't be using unstable in the first place... And when you compare the situation of PyQt3/PyQt4 to that of old/new sip version your comparing apples and pears. The proper comparison would be between 2 different versions of PyQt4, which cannot be installed together and you might have a similar problem there. Andreas -- Courage is your greatest present need. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
On Saturday 04 November 2006 7:47 pm, Simon Edwards wrote: Hello, One of the things that I would like to see in PyKDE 4 is the possibility to install different versions PyQt into the same Python installation in the event that backward compatibility in libsip needs to be broken. Anyway, I've done a bit of exploratory programming regarding making it possible to install and use two versions of SIP+PyQt which use a different libsips. The idea is that different versions of PyQt could be installed as different modules (PyQt_v4, and PyQt_v5 for example), and using a couple of module loading tricks it should be possible for PyQt4 programs to work so as they now work. Python programs that contain a C++ class compiled against a specific version of libsip, can then specify which version of libsip they need. To illustrate by example: ... from PyQt import QtCore ... Gets the default latest PyQt version, while this explicitly requests a the installed version of PyQt that uses sip2. ... import sip2 from PyQt import QtCore ... Later the program could load its own C++ class that uses the same version of libsip without the whole thing blowing up. My experiment is in the zip file attached to this email. (I hope it gets through to the list). This would be very useful for PyKDE and KDE 4. Phil, what do you think? Yuck. So, in the hypothetical case where a binary incompatibility is introduced you then go through all your existing applications and change the Python source code??? If you want module version dependencies then don't eggs give you what you need? Why do you think there is something called libsip that a C++ class is compiled against? Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
On Saturday 04 November 2006 21:38, Phil Thompson wrote: On Saturday 04 November 2006 7:47 pm, Simon Edwards wrote: This would be very useful for PyKDE and KDE 4. Phil, what do you think? Yuck. So, in the hypothetical case where a binary incompatibility is introduced you then go through all your existing applications and change the Python source code??? It only applies to code brings its own wrapper C+ classes. It would be the responsibility of the developer of the application to keep any explicit import sipX statements in sync with what they are using to compile their wrappers for their custom C++ classes. If you want module version dependencies then don't eggs give you what you need? From what little I just read about python eggs, it looks like it kind of does the things that I'm after. Would PyQt be able to fit into such a system? I'm, supporting multiple versions and all? Why do you think there is something called libsip that a C++ class is compiled against? sip.so. Point is, once a SIP wrapper for a custom C++ class is compiled it then depends on that particular version of sip. Trying to run a program that uses a PyQt compiled for sip version X, and uses a custom C++ class compiled for sip version Y, will fail. Python programs can't mix two versions of sip. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
On Saturday 04 November 2006 10:08 pm, Simon Edwards wrote: On Saturday 04 November 2006 21:38, Phil Thompson wrote: On Saturday 04 November 2006 7:47 pm, Simon Edwards wrote: This would be very useful for PyKDE and KDE 4. Phil, what do you think? Yuck. So, in the hypothetical case where a binary incompatibility is introduced you then go through all your existing applications and change the Python source code??? It only applies to code brings its own wrapper C+ classes. It would be the responsibility of the developer of the application to keep any explicit import sipX statements in sync with what they are using to compile their wrappers for their custom C++ classes. But a binary incompatibility is an issue for the person compiling and installing the wrappers, not for the person writing them. The wrappers could work perfectly well with either incompatible SIP versions without change. If you want module version dependencies then don't eggs give you what you need? From what little I just read about python eggs, it looks like it kind of does the things that I'm after. Would PyQt be able to fit into such a system? I'm, supporting multiple versions and all? I'm not an egg expert either - in particular I don't know if it has issues with extension modules rather than pure Python modules. Why do you think there is something called libsip that a C++ class is compiled against? 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. Trying to run a program that uses a PyQt compiled for sip version X, and uses a custom C++ class compiled for sip version Y, will fail. Python programs can't mix two versions of sip. 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). Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Multiple PyQt version in one Python installation
On 04.11.06 23:29:08, Phil Thompson wrote: On Saturday 04 November 2006 10:08 pm, Simon Edwards wrote: On Saturday 04 November 2006 21:38, Phil Thompson wrote: If you want module version dependencies then don't eggs give you what you need? From what little I just read about python eggs, it looks like it kind of does the things that I'm after. Would PyQt be able to fit into such a system? I'm, supporting multiple versions and all? I'm not an egg expert either - in particular I don't know if it has issues with extension modules rather than pure Python modules. I'm not an egg expert either, but I do know that you can use extension modules with them. lxml for example links against libxml2 and provides a python interface on top of it. It uses pyrex for the wrapping part and is available as egg on cheeseshop. I think the most problematic part for getting PyQt as egg is integrating the PyQt buildsystem (and sips probably too) into the setuptools. Andreas -- Time to be aggressive. Go after a tattooed Virgo. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
