serfmake assumes /usr/bin/python

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Check out the svn trunk of serf.
2. Run serfmake: ./serfmake --prefix=/usr/local/serf --with-apr=/usr/local/apr  

What is the expected output?
The normal output of serfmake.

What do you see instead?
{{{
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./serfmake", line 3, in ?
    import os
  File "/usr/local/lib/python2.5/os.py", line 134
    from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep,
                        ^
SyntaxError: invalid syntax
}}}

What version of the product are you using?
trunk r1124.

On what operating system?
Mac OS X 10.4.10. The system-installed Python, at /usr/bin/python, is version 
2.3.5. The version 
of Python I installed myself, at /usr/local/bin/python, is version 2.5.1.

Please provide any additional information below.
The simplest solution to this problem is to change the shebang to:

{{{
#!/usr/bin/env python
}}}

The python executable to be run will be chosen by env from the user's PATH.

Original issue reported on code.google.com by boredzo on 27 Aug 2007 at 5:35

[GoogleCodeExporter]

This doesn't make sense.  If serfmake is running /usr/bin/python, why is it 
loading
/usr/local/lib/python2.5/os.py?  
What is your PYTHONPATH set to?

This looks like either a mis-match between /usr/bin/python and PYTHONPATH, or a
broken install.

The "env python" approach has it's own issues.  You can always explicitly call 
the
right python with the script.

-Dan C

Original comment by DanChris...@gmail.com on 27 Aug 2007 at 9:51

[GoogleCodeExporter]

PYTHONPATH is set to:

{{{
/Users/prh/Python:/usr/local/lib/python2.5:/usr/local/lib/python2.5/plat-darwin:
/usr/local/lib/python2.5/
plat-darwin/MacToolbox:/usr/local/lib/python2.5/lib-tk:/usr/local/lib/python2.5/
lib-dynload:/usr/local/lib/
python2.5/site-packages
}}}

It is not a broken installation of Python; I've been using this installation of 
it for months.

> You can always explicitly call the right python with the script.

Yes; I'm just not used to doing that. ☺ Especially when it's not something 
Python-*related*, but simply a 
command-line tool *written in* Python (which could just as well be written in 
Perl or Ruby or Java or shell-
script).

The bug is not the “import site failed” error message; that's expected, 
given the mismatch. The bug (a term 
which I use *very* loosely here) is the mismatch itself, that the script is 
written with the assumption that the 
correct python is /usr/bin/python.

If `env python` is objectionable (for reasons which I assume include the 
possibility of PATH attacks?), perhaps 
the script could be wrapped in a shell trampoline that invokes “which 
python”, then asks the user whether this 
is the proper python to use.

Original comment by boredzo on 27 Aug 2007 at 10:17

[GoogleCodeExporter]

I checked with my local python expert and he says that env is a somewhat better 
way
to go.  

It's still not perfect.  You might get a horribly old version or some weird (or
hacked) thing.  This doesn't eliminate the possibility that the python and the 
user's
PYTHONPATH are incompatible.

Customizing it with an installer or wrapper script is best, but that seems 
painful
for a build tool.

-Dan C

Original comment by DanChris...@gmail.com on 28 Aug 2007 at 12:28

[GoogleCodeExporter]

Changed to "#!/usr/bin/env python" in r1181 as suggested here and responding to
another user's report.

Original comment by lieven.govaerts@gmail.com on 16 Apr 2008 at 5:55

• Changed state: Fixed