Mailing List Archive

On Fri, 16 Apr 1999 21:20:11 GMT, Randall Hopper <aa8vb@vislab.epa.gov> wrote:

> If I want to augment my Python module search path inside a Python
>script (so that it affects itself and imported modules), what's the best
>way to do this?
>
>Randall

sys.path *is* already global, though only accessible via the
sys module's namespace. Just give it a try.

Stefan

Stefan Franke:
|Randall Hopper:
|> If I want to augment my Python module search path inside a Python
|>script (so that it affects itself and imported modules), what's the best
|>way to do this?
|
|sys.path *is* already global, though only accessible via the
|sys module's namespace. Just give it a try.

I'd already tried that. It's effect doesn't appear to be global:

# Augment search path to pull in our C library wrappers
sys.path.insert( 0, '/home/mylogin/Wrappers' )

import MapFile

This allows Python to find MapFile, but this doesn't allow MapFile to
import other modules in that same Wrappers directory.

Randall

[Stefan Franke]
> sys.path *is* already global, though only accessible via the
> sys module's namespace. Just give it a try.

[Randall Hopper]
> I'd already tried that. It's effect doesn't appear to be global:
>
> # Augment search path to pull in our C library wrappers
> sys.path.insert( 0, '/home/mylogin/Wrappers' )
>
> import MapFile
>
> This allows Python to find MapFile, but this doesn't allow MapFile to
> import other modules in that same Wrappers directory.

Randall, try posting a minimal set of failing code. This works for everyone
else on the face of the earth, so the hope is that in trying to whittle your
code down you'll come face to face with the demon who's clouding your mind
<wink>. If MapFile is C code, it's more likely that you're writing C-level
imports incorrectly.

debugging-as-exorcism-ly y'rs - tim

In that case the problem seems to be somewhere else. Can
you post the traceback, your directory layout and perhaps
some isolated code?

Your code snippet says :
# Augment search path to pull in our C library wrappers

Maybe importing C extensions makes your program fail?


The following example should resemble your situation (let
me know if it doesn't):

-------- file a.py in some_directory

# First, you can't import c
try:
import c
except ImportError:
print "import c failed"

# Patch sys.path
import sys
sys.path.append ("new_directory")

# b imports c with the new path
import b

-------- file b.py in some_directory

import sys
print sys.path

import c

-------- file c.py in some_directory/new_directory

print "This is c"

---------------------------

When I run this from the Python console it prints:

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import a
import c failed
['', 'D:\\Programme\\Python', 'D:\\Programme\\Pythonwin', 'D:\\Programme\\Python
[... long path snipped...]
me\\Python\\lib\\plat-win', 'D:\\Programme\\Python\\lib\\lib-tk', 'D:\\Programme
\\Python', 'D:\\Programme\\Python\\lib\\site-python', 'new_directory']
This is c


Stefan

* * *

On Sat, 17 Apr 1999 15:31:21 GMT, Randall Hopper <aa8vb@vislab.epa.gov> wrote:

>I'd already tried that. It's effect doesn't appear to be global:
>
> # Augment search path to pull in our C library wrappers
> sys.path.insert( 0, '/home/mylogin/Wrappers' )
>
> import MapFile
>
>This allows Python to find MapFile, but this doesn't allow MapFile to
>import other modules in that same Wrappers directory.
>
>Randall
>

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