Hi
Any ideas on installing multiple concurrent versions of wxPython?
Wanting to try things out in 2.5 with the minimal disruption (on Linux & Windows)...
David
PS Is wxDisplay included in wxPython 2.5 yet?
Any ideas on installing multiple concurrent versions of wxPython?
Wanting to try things out in 2.5 with the minimal disruption (on Linux &
Windows)...
Here's what I did on Linux. First, I compiled and installed wxGTK with
--prefix=$HOME/local. Then I built wxPython against that installation,
but did not install it.
When I want to use 2.5, I do:
export LD_LIBRARY_PATH=$HOME/local/lib:$LD_LIBRARY_PATH
export PYTHONPATH=$HOME/src/wxPythonSrc-2.5.1.5/wxPython
Your variables may be slightly different, but that works for me.
PS Is wxDisplay included in wxPython 2.5 yet?
At least under GTK, it is compiled in by default and wxPython uses it
correctly.
···
On Tue, Apr 20, 2004 at 12:00:03AM +0200, David Fraser wrote:
--
Brian
David Fraser wrote:
Any ideas on installing multiple concurrent versions of wxPython?
Wanting to try things out in 2.5 with the minimal disruption (on Linux & Windows)...
yes, there was a thread about this a little while ago. Essentially, in site-packages, you can re-name wx and wxPython to wx24 and wxPython24. Then install 2.5. Then name those: *25. When you want to switch, you can write a little script that creates links to one of those two directories as needed
This is what I have done on Linux:
/usr/local/bin/switchwxpy2.4 :
#!/bin/bash
cd /usr/local/lib/python2.3/site-packages
rm wx wxPython
ln -s wx2.4 wx
ln -s wxPython2.4 wxPython
/usr/local/bin/switchwxpy2.5 :
#!/bin/bash
cd /usr/local/lib/python2.3/site-packages
rm wx wxPython
ln -s wx2.5 wx
ln -s wxPython2.5 wxPython
On Windows, I don't think you can link, so you'll need to re-name instead.
I'm also considering a scheme where I put the wx and wxPython directories somewhere else entirely, and add that place to sys.path at the top of my wxPython programs, that way I can have various programs use different versions at the same time.
Robin: I'd REALLY like to have this be cleaner, and supported by the standard wxPython install. My suggestion is that wxPython gets installed into:
site-packages/wxXXX (with XXX) being the version number
(and wxPython, or is that going to be obsolete?)
You could put a link to wx if you want, so as not to change anything for people who don't want to change.
For this to work, ALL the stuff in the demo and libs would have to import this way"
import wxXXX as wx
now you could have any number of wxPython versions installed simultaneously, and they could all be used at the same time. I want this because I have a handfull of small utilities that use wxPython. When I upgrade, I need to go back and test and port all of them. I'd much rather just be able to specify the version when I write it, and just have it keep using that version until I have a reason to upgrade it. I also want to do this on OS_X, and I really don't want to have to make monster executables out of a small utility, just for this reason.
Maybe I'm missing something, but I can't see any reason not to do this.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Chris Barker wrote:
Robin: I'd REALLY like to have this be cleaner, and supported by the standard wxPython install. My suggestion is that wxPython gets installed into:
site-packages/wxXXX (with XXX) being the version number
(and wxPython, or is that going to be obsolete?)
You could put a link to wx if you want, so as not to change anything for people who don't want to change.
How many other popular Python pacakges do this?
For this to work, ALL the stuff in the demo and libs would have to import this way"
import wxXXX as wx
What about sub-packages? This won't work:
import wx251 as wx
import wx.lib.buttons
You would have to import them using the alternate name as well, and for some folks that would mean that lots of lines in a module would have to change.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
David Fraser wrote:
Hi
Any ideas on installing multiple concurrent versions of wxPython?
Wanting to try things out in 2.5 with the minimal disruption (on Linux & Windows)...David
PS Is wxDisplay included in wxPython 2.5 yet?
Thanks all for suggestions.
Here is what I did (on Fedora Linux):
moved my existing wx packages as follows
rpm -U --replacepkgs --relocate=/usr/lib/python2.3/site-packages/=/usr/lib/wxPython-2.4.2.4/python2.3/ --relocate=/usr/bin/=/usr/lib/wxPython-2.4.2.4/bin/ wxPythonGTK-py2.3-2.4.2.4-1.i386.rpm
(although this didn't remove the existing wxPython lib files for some reason, so I did it manually)
Then installed the new version in a different location
rpm -i --relocate=/usr/lib/python2.3/site-packages/=/usr/lib/wxPython-2.5.1.5/python2.3/ --relocate=/usr/bin/=/usr/lib/wxPython-2.5.1.5/bin/ wxPythonGTK2-py2.3-2.5.1.5-1.i386.rpm
I then put a simple script, wxmultiversion.py, in /usr/lib/python2.3/site-packages/
It reads as follows:
import os
import sys
wxversion = os.getenv("WXPYTHON_VERSION")
wxpath = None
if wxversion is None:
wxpath = os.getenv("WXPYTHON_PATH")
else:
wxpath = "/usr/lib/wxPython-%s/" % wxversion
if wxpath is not None and os.path.isdir(wxpath):
wxpythonpath = os.path.join(wxpath, "python%d.%d" % (sys.version_info[0], sys.version_info[1]))
if os.path.isdir(wxpythonpath):
sys.path.append(wxpythonpath)
Then I created a sitecustomize.py and put the line "import wxmultiversion" into it.
Now all I have to do is set either environment variable (WXPYTHON_VERSION or WXPYTHON_PATH) above and the right version of wx will be imported automatically.
Also some means could be added to detect which bin file to use...
The advantage of this approach is it doesn't depend on changing the filesystem which is a global setting, it just requires an environment variable.
Now the only problem is an import error under wxPython 2.5, but it shows the basic principle works
ImportError: /usr/lib/wxPython-2.5.1.5/lib/libwx_gtk2ud_core-2.5.so.1: undefined symbol: XineramaIsActive
David
Robin Dunn wrote:
Robin: I'd REALLY like to have this be cleaner, and supported by the standard wxPython install. My suggestion is that wxPython gets installed into:
site-packages/wxXXX (with XXX) being the version number
(and wxPython, or is that going to be obsolete?)
You could put a link to wx if you want, so as not to change anything for people who don't want to change.
How many other popular Python pacakges do this?
I don't think I've ever seen it, but all the major packages I've used (mxDateTime, PIL, Numeric) have maintained a much more consistent API between versions that wxPython. I've never had to change any code in an upgrade of these. I think that's because they are MUCH smaller, more focused packages, and maybe more mature.
However, Python itself does do this, and it is very helpful on *nix systems. I'm not so sure about Windows, as I think you need to connect *.py to a given application, so it can only be one version. On OS-X, Jack set up PythonLauncher to read the #! line, so it works there. (at least I think it does, I've haven't tested it there, as using anything other than 2.3 on OS-X is painful at this point anyway)
The other solution is to just upgrade wxPython in lockstep with Python, but I think would be too limiting. I have no idea when Python 2.4 might come out, but I'm sure I don't want to wait for it before I start using wxPython 2.5.*. IN another few years, wxWidgets/wxPython may get mature enough that we could sync up the upgrades, but that's a while off..
I'm not pretending that I have thought this through very well, but I do know that the issue of versioning of Python has been under-addressed, and I'd really like this to work out well. It seems the standard answer is to use Py2exe or the like to deliver your software, and that way you have control of what gets used. This is fine if you are delivering a single, substantial application, but if you want to deliver a handful of small utilities, the packages sizes just get ridiculous. Valid or not, this is a major problem when trying to sell Python as a viable platform for software development. What I'm trying to work toward is the ability to have a "wxPython Runtime", that could be installed along with your app, and then other apps could just use it, or replace it with an updated one, without breaking older code. At some point, you might have ten versions of wxPython in the runtime, but I still think that's better than having twenty complete python +wxPython distributions all bundles up with a bunch of utilities. What I'm looking for in analogous to dynamically linked libraries. you can have different versions on he system at once because they have different names.
For this to work, ALL the stuff in the demo and libs would have to import this way"
import wxXXX as wx
What about sub-packages? This won't work:
import wx251 as wx
import wx.lib.buttonsYou would have to import them using the alternate name as well, and for some folks that would mean that lots of lines in a module would have to change.
Yes, I guess you would. This makes me wonder if the package import system should be re-worked to accommodate this kind of thing. In fact, the current method seems to violate importing semantics. If wx251 has been imported, it should not be imported again with another import call. In this case, wx25 is both a module and a package. If you call
import wx251 as wx
again, it doesn't get re-imported, but if you call:
import wx251.something.something
wx251 gets scanned to look for the sub-packages. I like to think of packages as just the same as modules, except that they can contain modules, as well as other objects. Thinking this way, when wx251 is imported, a list of its sub-packages should be built, and that list used when a call to:
import wx251.something
is made, rather than the file system being re-scanned. If this were the case, you could do:
import wx251 as wx
import wx.something.somethingelse
...anyone have the energy for a PEP? In the meantime, a couple thoughts:
1) I did suggest a symlink to wx (is there a way to do something similar on Windows?), so anyone who didn't want to deal with this wouldn't have to, though I would want to see the versioned method the "officially recommended" one.
2) Somehow I still find importing nested packages confusing... is there a way to do something along the lines of:
A) import wx251.lib.buttons as wx.lib.buttons ?
or maybe we should just recommend:
B) from wx251.lib import buttons as wxbuttons
I don't like typing really long nested package names anyway.
It would certainly be better if users could just use "wx" everywhere except the import lines.
3) Perhaps the wx251 module could do some magic with sys.path, so that future "import wx.something. ..." would then find the right version. This would require the "real" wx being stored somewhere else on the file system than site-packages.
4) A different approach: put wx251 deeper in the structure:
from wxPythonVersions.251 import wx
from wxPythonVersions.251 import wx.lib.buttons
wxPythonVersions (or a shorter, catchier name) would live in site-packages. You could put a symlink:
site-packages/wx --> site-packages/wxPythonVersions/251/wx
for backward compatibility. Again, this requires a symlink...is there a way to do something like that in Windows?
I think option (4) might be the best, with option (2A) being perfectly acceptable to me.
I think there are enough questions (and different solutions) on this list about how to accomodate different versions that there is clearly a need for a standard solution.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
David Fraser wrote:
[...]
Now the only problem is an import error under wxPython 2.5, but it shows the basic principle works
ImportError: /usr/lib/wxPython-2.5.1.5/lib/libwx_gtk2ud_core-2.5.so.1: undefined symbol: XineramaIsActive
I think Xinerama is used by the wxDisplay class. Perhaps your X libs were built without it? Or maybe it's in a separate lib? Either way, try rebuilding from the SRPM.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
David Fraser wrote:
Here is what I did (on Fedora Linux):
...
I then put a simple script, wxmultiversion.py, in /usr/lib/python2.3/site-packages/
Now all I have to do is set either environment variable (WXPYTHON_VERSION or WXPYTHON_PATH) above and the right version of wx will be imported automatically.
Also some means could be added to detect which bin file to use...
The advantage of this approach is it doesn't depend on changing the filesystem which is a global setting, it just requires an environment variable.
why not get rid of the environment variable altogether, and have something like:
import wxmultiversion
wxmultiversion.SetVersion("2.5.1")
that way you could have stand-alone python scripts that did the right thing, without having to set an environment variable ahead of time.
I'd still much rather have the standard install support this (see a note I just posted), but I may do this on my systems if it doesn't.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Chris Barker writes:
I think there are enough questions (and different solutions)
on this list about how to accomodate different versions that
there is clearly a need for a standard solution.
Chris, great post. You've touched on issues that have plagued
all of us, I'm sure. The only thing I have to offer at this
point is the fact that at PyCon Guido mentioned the need for
making Python's import facilities much more powerful as Python
moves forward. Better relative imports, etc. Perhaps there is
already a PEP being written on this.
···
--
Paul
Robin Dunn wrote:
David Fraser wrote:
[...]Now the only problem is an import error under wxPython 2.5, but it shows the basic principle works
ImportError: /usr/lib/wxPython-2.5.1.5/lib/libwx_gtk2ud_core-2.5.so.1: undefined symbol: XineramaIsActiveI think Xinerama is used by the wxDisplay class. Perhaps your X libs were built without it? Or maybe it's in a separate lib? Either way, try rebuilding from the SRPM.
Thanks, I just used the standard GTK instead of GTK2 classes and it solved this. Will try this if I want GTK2
David
Chris Barker wrote:
[...much food for thought...]
for backward compatibility. Again, this requires a symlink...is there a way to do something like that in Windows?
On XP (and maybe 2k??) you can have what is called a Junction, which is basically the same as a directory symlink, but it requires third-party utilities to create it as there is no way from the standard UI or the command-line to do it.
I think there are enough questions (and different solutions) on this list about how to accomodate different versions that there is clearly a need for a standard solution.
This discussion should probably be taken to comp.lang.python as I'm not sure I want to blaze new trails on this... Please restate the background of the issue and your ideas there and let's see what suggestions come back.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Chris Barker wrote:
David Fraser wrote:
Here is what I did (on Fedora Linux):
...
I then put a simple script, wxmultiversion.py, in /usr/lib/python2.3/site-packages/
Now all I have to do is set either environment variable (WXPYTHON_VERSION or WXPYTHON_PATH) above and the right version of wx will be imported automatically.
Also some means could be added to detect which bin file to use...
The advantage of this approach is it doesn't depend on changing the filesystem which is a global setting, it just requires an environment variable.why not get rid of the environment variable altogether, and have something like:
import wxmultiversion
wxmultiversion.SetVersion("2.5.1")that way you could have stand-alone python scripts that did the right thing, without having to set an environment variable ahead of time.
The main reason I was wanting an environment variable was that I want to be able to use different versions of wxPython with different applications *without* altering either the applications or the filesystem. But it would be good to have an intelligent version-determining capability (with a default fallback version) that could be overridden with an environment variable etc.
I'd still much rather have the standard install support this (see a note I just posted), but I may do this on my systems if it doesn't.
Well it would be nice to see what can be implemented now the minimum of alterations to the import mechanism or wxPython ... but I agree that Python needs a more robust mechanism for handling this generally.
David
Robin Dunn wrote:
for backward compatibility. Again, this requires a symlink...is there a way to do something like that in Windows?
On XP (and maybe 2k??) you can have what is called a Junction, which is basically the same as a directory symlink, but it requires third-party utilities to create it as there is no way from the standard UI or the command-line to do it.
well, given that, and the fact that people will be running pre-XP versions of Windows for a long time to come, a method that doesn't require sym-links will be necessary. Another reason I stay away from Windows...
I think there are enough questions (and different solutions) on this list about how to accomodate different versions that there is clearly a need for a standard solution.
This discussion should probably be taken to comp.lang.python as I'm not sure I want to blaze new trails on this... Please restate the background of the issue and your ideas there and let's see what suggestions come back.
Well, I'd love to have a python standard for this, but at best, that will take a good while, so we might as well come up with something that wxPython can use. I'll make a post to comp.lang.python, but I honestly can't afford to take the time to really follow this through. Who knows? maybe someone will have a good idea that we can implement now.
What are your thoughts on option (4) from my previous post:
Put wx251 deeper in the structure:
from wxPythonVersions.251 import wx
from wxPythonVersions.251 import wx.lib.buttons
wxPythonVersions (or a shorter, catchier name) would live in site-packages.
Without a symlink, you couldn't keep the "import wx" option, but this would only require a change to folks' import lines, nothing more. The move to 2.5* requires more changes than that anyway.
I could be missing something, however.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Chris Barker wrote:
Robin Dunn wrote:
for backward compatibility. Again, this requires a symlink...is there a way to do something like that in Windows?
On XP (and maybe 2k??) you can have what is called a Junction, which is basically the same as a directory symlink, but it requires third-party utilities to create it as there is no way from the standard UI or the command-line to do it.
well, given that, and the fact that people will be running pre-XP versions of Windows for a long time to come, a method that doesn't require sym-links will be necessary. Another reason I stay away from Windows...
I think there are enough questions (and different solutions) on this list about how to accomodate different versions that there is clearly a need for a standard solution.
This discussion should probably be taken to comp.lang.python as I'm not sure I want to blaze new trails on this... Please restate the background of the issue and your ideas there and let's see what suggestions come back.
Well, I'd love to have a python standard for this, but at best, that will take a good while, so we might as well come up with something that wxPython can use. I'll make a post to comp.lang.python, but I honestly can't afford to take the time to really follow this through. Who knows? maybe someone will have a good idea that we can implement now.
I presume the comp.lang.python post will focus on extensions to the import mechanism, but discussion of a simple wx solution is still relevant here...
What are your thoughts on option (4) from my previous post:
Put wx251 deeper in the structure:
from wxPythonVersions.251 import wx
from wxPythonVersions.251 import wx.lib.buttonswxPythonVersions (or a shorter, catchier name) would live in site-packages.
Without a symlink, you couldn't keep the "import wx" option, but this would only require a change to folks' import lines, nothing more. The move to 2.5* requires more changes than that anyway.
I could be missing something, however.
The main problem with this is that you have to change the application source to change the version number.
If you use a wxmultiversions approach you can at least modify sys.path, and then proceed as normal...
import wxmultiversion
wxmultiversion.set_required("2.4")
wxmultiversion.set_preferred("2.5")
import wx
It would be nice to have a standard wxmultiversion module where you could specify required major/minor version numbers, and it would find the appropriate version...
David
David Fraser wrote:
Chris Barker wrote:
Robin Dunn wrote:
for backward compatibility. Again, this requires a symlink...is there a way to do something like that in Windows?
On XP (and maybe 2k??) you can have what is called a Junction, which is basically the same as a directory symlink, but it requires third-party utilities to create it as there is no way from the standard UI or the command-line to do it.
I'd consider using a path file to control this.
In site-packages: "wx24/wx" and "wx24/wxPython" and "wx25/wx" and ...
Also in site-packages:
wxpython.pth
A simple text file with the directory name to use for wxPython
(either wx24 or wx25 in this example).
-Scott David Daniels
Scott.Daniels@Acm.Org
Chris Barker wrote:
[...]
What are your thoughts on option (4) from my previous post:
I think it's a bit too unwieldy, but I'm still thinking about it.
···
Put wx251 deeper in the structure:
from wxPythonVersions.251 import wx
from wxPythonVersions.251 import wx.lib.buttonswxPythonVersions (or a shorter, catchier name) would live in site-packages.
Without a symlink, you couldn't keep the "import wx" option, but this would only require a change to folks' import lines, nothing more. The move to 2.5* requires more changes than that anyway.
I could be missing something, however.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
I have an idea:
I tested it and it kindda works 
so:
one small script in "site-packages" called wxver.py
def setver(ver="wx24"):
import os
import sys
base = "C:\\wxs"
try:
sys.path.append(os.path.join(base,ver))
except:
print "oopsie"
and a directory with all the versions of wxpython in my case "C:\\wxs"
Now to run an app just use a script like this one: (run.py)
import wxver
wxver.setver("wx25")
import cms
cms.main()
where cms is my main script. No change is necessary in the rest of the scripts and if I want to test my app with other versions of wxpython all I have to do is install the version in the wxs directory and change one line in the run.py script.
···
--
Peter Damoc
Hacker Wannabe
http://www.sigmacore.net/about.html
I'd certainly use wxpython.pth instead of symlinks, because
it's a single solution that works cross-platform.
Neither symlinks, folder-renaming, nor wxpython.pth solves
this use-case:
- Single installation of single Python version (e.g., 2.3.2)
- Program A requires wx24 (not converted for wx25)
- Program B requires wx25 (converted, so won't run with wx24)
- User runs A
- User runs B (without killing A)
This is, I think, the generic case.
It may be resolved on *nix by starting via a shell script
that sets PYTHONPATH, or on Windows via a .bat file that
starts a new cmd shell with the appropriate PYTHONPATH.
But in either case, this approach would require not only
two different versions of wxPython, but two different
installs of Python (even if the same version).
Sorry, but that dog don't hunt.
Something that allows the app to specify, before it
imports wxPython (or any part of it), what version is
desired, would be preferable.
Perhaps something like
requireVersion( 'wxPython', '2.5' )
def requireVersion( module, earliestVersion=None, latestVersion=None,
versions=None ):
"""
@param earliest: Earliest version of module with which app can run.
@param latest: Latest version of module with which app can run.
@param versions: Sequence of version numbers of module
with which app can run.
Version strings may contain asterisks as wildcards
(e.g., '2.5.*' would match 2.5 or any 2.5 subversion).
If none of the specified versions is found, raises an exception.
"""
Unfortunately, this would require changes to Python's
import machinery, not just changes to wxPython.
- Sam
···
At 2004-04-21 09:00 AM -0700, you wrote:
David Fraser wrote:
Chris Barker wrote:
Robin Dunn wrote:
for backward compatibility. Again, this requires a symlink...is there a way to do something like that in Windows?
On XP (and maybe 2k??) you can have what is called a Junction, which is basically the same as a directory symlink, but it requires third-party utilities to create it as there is no way from the standard UI or the command-line to do it.
I'd consider using a path file to control this.
In site-packages: "wx24/wx" and "wx24/wxPython" and "wx25/wx" and ...
Also in site-packages:
wxpython.pthA simple text file with the directory name to use for wxPython
(either wx24 or wx25 in this example).-Scott David Daniels
Scott.Daniels@Acm.Org
__________________________________________________________
Spinward Stars, LLC Samuel Reynolds
Software Consulting and Development 303-805-1446
http://SpinwardStars.com/ sam@SpinwardStars.com
from wxPythonVersions.251 import wx
from wxPythonVersions.251 import wx.lib.buttons
I am not knowledgeable about the difficulties of implementing
one of Chris's proposals, but if it is feasible, I cast my vote for
doing so. These appear to be simple, error-minimizing methods
for users to use alternate versions.
While some have figured out alternate ways to get around this
problem, they are more for computer specialists. These types
of solutions are a general weakness that open-source software
is trying to overcome: the need for specialized knowledge on
the part of users, as well as the time to try (and retry and retry)
solutions for each machine. We can't use the reasoning that
'any competent user can modify their system in this way'--many
intelligent users simply don't have the time to become this
expert, and there are often unintended side effects of
systems modifications. In fact, such users are wise to resist
modifying their set-ups whenever a particular piece of software
requests it.
To help a developer distribute software to a wide variety of users,
syntax like the above would be helpful.
John
John Li wrote:
from wxPythonVersions.251 import wx
from wxPythonVersions.251 import wx.lib.buttons
I am not knowledgeable about the difficulties of implementing
one of Chris's proposals, but if it is feasible, I cast my vote for
doing so. These appear to be simple, error-minimizing methods
for users to use alternate versions.
While some have figured out alternate ways to get around this
problem, they are more for computer specialists. These types
of solutions are a general weakness that open-source software
is trying to overcome: the need for specialized knowledge on
the part of users, as well as the time to try (and retry and retry)
solutions for each machine. We can't use the reasoning that
'any competent user can modify their system in this way'--many
intelligent users simply don't have the time to become this
expert, and there are often unintended side effects of
systems modifications. In fact, such users are wise to resist modifying their set-ups whenever a particular piece of software requests it.
To help a developer distribute software to a wide variety of users,
syntax like the above would be helpful.
The trouble with the above syntax is that it may make life *more* difficult for users by requiring them to have the exact version of wx the programmer specified.
An intelligent method of picking up the most appropriate version would be easier for users...
David