I just posted this over on Ben Last's blog. Since this is an issue many people are faced with when contemplating upgrading to wxPython 2.5.x, it should get wider coverage and discussion. As some of you on this list will realize, there are situations when this "trick" could go horribly wrong, most notably if your wxPython code is using the newer wx package and you happen to import another package or module that is using the wxPython.wx package or vice versa. As mentioned in my post below, the best thing is probably to rename the package that isn't supposed to get used and see if anything breaks because of a failed import. On my system I typically have the wxPython dir renamed, so there is ONLY a wx package and if there is a rogue wxPython.wx reference I can spot it quick and change it.
http://www.livejournal.com/users/benlast/16907.html
Happy hacking!
···
---
I used this trick during the initial wxPython 2.5.1.5 release on Windows and I'm sure it works, as long as you know that the application you want to run is consistent about its use of wxPython packages. The old wxPython package was wxPython.wx so typically you would see people using it as:
from wxPython.wx import *
or
from wxPython import wx
There was an experimental package in later 2.4.x releases called wx, so if you look in site-packages you'll see wx and wxPython directories. There was a magical set of import statements that imported all the wxPython.wx stuff and did namespace manipulation for the wx package in anticipation of the new wx package that would be adopted with wxPython 2.5.x and later.
As of wxPython 2.5.x the real package is wx and now the wxPython package does the magical imports and namespace manipulation to provide backward compatability for code that still uses the old imports form above. Newer packages designed to work with wxPython 2.5.x and later use imports of the form:
import wx
or if you still believe namespace collisions will never happen to you
from wx import *
So, what's this got to do with living in both worlds? If you have wxPython 2.4.2.4 installed, then go into your site-packages directory and rename the wx dir to wx24 and the wxPython dir to wxPython24. Now install wxPython 2.5.2.7. Rename the wxPython dir to wxPython25 and then rename the wxPython24 dir to wxPython. Voila, now you can live in both worlds. PythonCard will never import from wxPython.wx so there won't be a conflict between 2.4.2.4 and 2.5.2.7 libraries and a package like Boa will always be importing from wxPython.wx so it won't ever try and get something from the 2.5.2.7 wx package.
If you want to test this, simply rename the wx package back to wx25 and run your code that requires wxPython 2.4.x. If anything ever tries to import from wx then an exception will be thrown. Similarly, you can test that code that wants 2.5.x doesn't ever import from wxPython.wx by renaming the wxPython dir back to wxPython24.
I never tested this on Linux and the process might be more complicated if the underlying wxGTK libs don't live under the wx and wxPython dirs, but it works like a champ on Windows. If you are running Mac OS X, you simply shouldn't run wxPython 2.4.x, wxPython 2.5.2.7 on Mac OS X is so much better, so just upgrade!
I'll go ahead and post about this on my own blog tomorrow, but you can email at altis@semi-retired.com if this works or doesn't work for you.
ka
---
Kevin Altis
altis@semi-retired.com
http://altis.pycs.net/