Michael Barton wrote: > > We also need to ensure that the wxPython 2.8 package *does* get used > > by GRASS even though it doesn't get used by anything else which uses > > wxPython. > > > > Here, I set LD_LIBRARY_PATH and PYTHONPATH manually before running > > wxgrass. I'm not sure how easy it would be for GRASS to automate that, > > given that wxPython 2.8 is likely to be installed in such a way that > > it would normally be "invisible" to packages which use wxPython. > > Good points. I remember some directions at the wxPython download site for > installing wxPython in non-standard locales and installing multiple > versions. Maybe we could use those suggestions to deal with this.
It can certainly be done; the issue is the effort required to do it reliably without user intervention. Off the top of my head: wxgrass will need to: 1. Catch any exceptions which arise from "import wx" (i.e. no wxPython as part of the standard Python installation) or "import wx.aui" (i.e. wxPython < 2.8). 2. Attempt to locate wxPython 2.8, by looking for directories where it is likely to be found (i.e. wherever the provided binary packages put it). 3. Re-invoke itself, after having updated LD_LIBRARY_PATH (or the equivalent for other platforms) and PYTHONPATH accordingly. If the user has built wxPython 2.8 themselves, or is using a binary package installed in a location unknown to #2, they will need to set LD_LIBRARY_PATH (etc) and PYTHONPATH themselves; that will prevent any exceptions at #1 (i.e. the package will appear to be part of the standard wxPython installation so far as wxgrass is concerned). -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
