I ran into a small problem this weekend while working on a potential redesign of _tkinter.c that I thought I should bring up here.
This is not so much a change to distutils code, or the addition of a feature. But it is a big "gotcha" on UNIX, where shared objects could reside in different directories (as has been discussed here lately).
Just to give a little rundown of the problem. A few weeks ago, someone on c.l.py asked if there was a Tcl interpreter extension. Some people (including myself) stated that there was one in Tkinter, but couldn't divorce yourself from Tk. So I got it in my head to make a Tcl module then redesign _tkinter.c to use that module instead.
Now the problem: To be thread safe (especially with Tcl8.0), there is a global lock object used when entering all the Tcl/Tk code. This object should be shared between the two modules (it is using the same Tcl_Interp object). Not a problem, right? In the Python init_tkinter() function, simply import the Tcl module and get access to the global data in the shared module. The import.c code would load the dynamic modules and handle it.
Not quite. When the _tkinter.so loads, it attempts to load the Tcl module shared object as well, not based on sys.path but on LD_LIBRARY_PATH (or what every was set at link-time).
I got around this by making a PyCObject out of the Tcl lock object in the module, then accessing that inside init_tkinter(), thereby making no references to the Tcl module.
Now to my point to all this. I have two, in fact.
First, when writing modules, try not rely on global data in other Python modules unless it is thru the Python API. You might find that your runtime link-editor can't handle finding the shared library file.
Second, it may not always be enough to place the shared object modules in site-packages or the like. I can easily imagine that SWIG might make references to something inadvertently that is outside the view that import.c (or the imp module) has of the world.