Reputation: 497
Can someone explain why this code shows a new version of Python on Dreamhost ?
import sys,os
# Force Passenger to run our virtualenv python
INTERP = "/home/site/env/bin/python"
if sys.executable != INTERP: os.execl(INTERP, INTERP, *sys.argv)
def application(environ, start_response):
start_response('200 OK', [('Content-type', 'text/plain')])
return ["Hello, world!" + sys.version]
While this code shows an old version :
#!/home/site/env/bin/python
import sys
def application(environ, start_response):
start_response('200 OK', [('Content-type', 'text/plain')])
return ["Hello, world!" + sys.version]
Upvotes: 0
Views: 1685
Reputation: 34813
If you throw some debugging code in passenger_wsgi.py
to write out a log file:
x = open(os.path.expanduser('~/log.log'), 'w')
x.write(repr(sys.argv))
x.close()
and then examine ~/log.log
, then you’ll find that the python process that loads passenger_wsgi.py
is started by running /dh/passenger/lib/phusion_passenger/wsgi/request_handler.py
.
The first line of /dh/passenger/lib/phusion_passenger/wsgi/request_handler.py
is
#!/usr/bin/env python
and it loads passenger_wsgi.py
by calling
app_module = imp.load_source('passenger_wsgi', 'passenger_wsgi.py')
Since passenger_wsgi.py
is loaded as a Python module, the #!/home/site/env/bin/python
line at the start of your second passenger_wsgi.py
file is treated simply as a Python comment and ignored. The default /usr/bin/python
is used instead.
The recommended fix for this is exactly what your first passenger_wsgi.py
does: execl
the version of Python you actually want. I usually compile Python 2.7 in the shell user’s home directory and use that.
PS: If you’re curious I have some notes about setting up Django on Dreamhost so that you can do continuous deployment…
Upvotes: 1