|Friday, August 20, 2004|
How to live on the edge with wxPython and not get cut (i.e. using wxPython 2.4.x and 2.5.x simultaneously).
I used this trick during the initial wxPython 18.104.22.168 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 *
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:
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 22.214.171.124 installed, then go into your site-packages directory and rename the wx dir to wx24 and the wxPython dir to wxPython24. Now install wxPython 126.96.36.199. 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 188.8.131.52 and 184.108.40.206 libraries and a package like Boa will always be importing from wxPython.wx so it won't ever try and get something from the 220.127.116.11 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 18.104.22.168 on Mac OS X is so much better, so just upgrade!
8:01:57 AM comment