From: aa8vb at vislab.epa.gov (Randall Hopper)
Date: Mon, 19 Apr 1999 13:14:38 GMT
Subject: sys.path.insert - how to make it global?
In-Reply-To: <01E40461E003D21195CC0080296495D80B1309@gates.cdc-group.com>; from Stefan Franke on Sat, Apr 17, 1999 at 06:35:32PM +0200
References: <01E40461E003D21195CC0080296495D80B1309@gates.cdc-group.com>
Message-ID: <19990419091438.A59861@vislab.epa.gov>
Content-Length: 1331
X-UID: 1655                                                  

Stefan Franke:
 |Your code snippet says :
 |  # Augment search path to pull in our C library wrappers
 |
 |Maybe importing C extensions makes your program fail?

Yes, exactly.

 |The following example should resemble your situation (let
 |me know if it doesn't):
 |
 |-------- file a.py in some_directory
 |-------- file b.py in some_directory
 |-------- file c.py in some_directory/new_directory

This works fine here as well.  At the time I'd suspected that this was an
issue with importing in general, but it's actually shared library importing- 
specific.

Simplifying my situation and drawing parallels to yours, my case was:

 -------- file A.py in some_directory
 -------- file B.py in some_directory/new_directory
 -------- file C.so in some_directory/new_directory
 -------- file D.so in some_directory/new_directory

A imports B which imports C which is linked with D.  It failed pulling in
D.  B are SWIG shadow classes, C.so is the SWIG Python wrappers for a C
library, and D.so is the C library itself (several of them actually).

Augmenting the RPATH established when C is built to include where D lives
resolved my problem not being able to import B from A.

So I know now that augmenting sys.path isn't sufficient when some of the
Python modules have dependent shared libraries.

Thanks for your help,

Randall





