Not finding user-installed module despite PYTHONPATH!

Robin Munn rmunn at pobox.com
Mon Dec 2 14:04:11 EST 2002


Albert Hofkamp <hat at se-46.wpa.wtb.tue.nl> wrote:
> On Fri, 29 Nov 2002 19:08:42 GMT, Robin Munn <rmunn at pobox.com> wrote:
>> Albert Hofkamp <hat at se-46.wpa.wtb.tue.nl> wrote:
>>> 
>>> I want to run an interactive Python module through ssh. The basic solution is
>>> something like
>>> 
>>> ssh -x remote_machine 'python -c "import mymodule ; mymodule.run()"'
>> 
>> [snip attempts to get PYTHONPATH set]
>> 
>> Does something like this work?
>> 
>> ssh -x remote_machine 'PYTHONPATH=/path/to/module python -c "import mymodule ; mymodule.run()"'
>> 
>> (If that line wraps, it should be all on one line).
> 
> (it didn't)
> At first sight, there seems to be a ; missing before 'python'. Also,
> some shells may need something like 'export' or 'setenv' at the beginning.
> (I will try this option, but near the end of the week or later).

No, there is no semicolon missing. This is standard syntax for
temporarily setting an environment variable under the Bourne shell (or
its descendants, such as bash). The generalized syntax is:

    VARIABLE=value program arguments

Or, if you want to set several environment variables:

    VAR1=val1 VAR2=val2 VAR3=val3 program arguments

If you have a copy of Unix Power Tools, see recipe 6.10 (page 100 in the
second edition, might be a different page number in the third edition).

However, this only works with the Bourne shell. See below for a more
generalized solution.

> 
>> It seems to me that this might be a better solution than trying to set
> 
> I am a bit afraid what assumptions you make above w.r.t. the used shell
> (e.g. must I use export or setenv?).
> 
> The overall idea was
> a) make as little assumptions about the remote system as possible
> b) make it easy to maintain.
> c) make it easy to explain to non-unix experts.
> 
> I think I cannot comply to all these conditions with either
> ".ssh/enivronment" or with "PYTHONPATH="
> 
> What worries me most is c). The entire problem is in my view a Unix problem
> which should be dealt with by configuring shells, etc. It is not part of
> the module functionality, yet it looks like I will need to spend at least
> half a page of text to this problem :-(

It seems to me that configuring shells, etc. violates requirement a). I
was explictly trying to make as little assumptions *and* modifications
about the remote system as possible. In other words, the environment on
the remote system should *not* need to be touched. Therefore the
appropriate environment variable must be set in a temporary way.

By the way, having looked up recipe 6.10 in my copy of Unix Power Tools,
I notice that the solution I gave you only applies if the remote machine
is going to be running the Bourne shell. Here's a more generalized
solution that should apply even if the machine is running the C shell:

ssh -x remote_machine 'env PYTHONPATH=/path/to/module python -c "import mymodule ; mymodule.run()"'

The only assumption this makes is that the 'env' program is available.
This program *should* be standard on any Unix made in the past fifteen
years or so -- someone please correct me if I'm wrong.

> 
>> .ssh/environment -- do you want *all* ssh sessions to get this
>> PYTHONPATH, or just this particular command?
> 
> I want to make as few assumptions about the remote machine as possible. It
> should be possible to have my module installed at different places at
> different machines.
> That would mean that I would be specifying the place of 'module' in my
> program rather than let the system configuration handle it.

In that case, my proposed solution would definitely be the way to go: it
means no modification of the remote machine at all, and the path to the
module is only found in one place in one source code file, making for
easy code updates if the path ever changes. You could even flag it with
a comment:

    # ***** CHANGEME: Change the path below if the module ever moves *****
    ssh -x remotemachine ...

Replace 'CHANGEME' with whatever string makes sense to you and that you
would remember when trying to grep a source file for necessary
changes...

> 
>> I like to be as specific as possible, and not apply a too-general
>> solution that might not make sense in another case.
> 
> I have the experience that specific solutions tend to return to your desk,
> so I'd like to have a general solution and be rid of it for eternity.
> (but that only works if c) is done correctly, otherwise I end up explaining
> it to seperate individuals over and over again).

Overly specific solutions return to your desk, yes. But overly general
solutions will also tend to return to your desk, at times when you least
expect them. Say you modify the PYTHONPATH in the remote environment to
include '/usr/local/python-utils' or some such directory name. Then
someone else decides to put a module called "time" in that directory.
Suddenly a lot of code starts breaking, and you don't know why. My
philosophy on environment variables is only modify what you know you're
going to need, and only modify it for as little time as possible.

As for the need to explain your code to non-Unix experts, do you want to
be giving them a crash course on environment variables and the many
subtleties about using them (like how the environment passes from parent
process to child process but never in reverse, and the implications of
this on shell scripts)? Or do you just want to say "The python program
needs to have the PYTHONPATH environment variable set correctly to be
able to find the correct module; the call to 'env' accomplishes this."

Anyway, I hope this helps.

-- 
Robin Munn <rmunn at pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838    50FF 2478 CFFB 081A 8338  54F7 845D ACFD 6AFB 6838



More information about the Python-list mailing list