[Baypiggies] VirtualEnv and Django question

Simeon Franklin simeonf at gmail.com
Thu Feb 24 16:50:39 CET 2011

On Wed, Feb 23, 2011 at 6:07 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
>To keep this clean
> so there can be customized fields, we did this.
> In the settings.py file (that is in the repository), we have the following
> line (at the very bottom of the file):
> from local_settings import *

I think Eric Walstad already explained this but I do find the reverse
pattern more flexible. If at the bottom of settings you import
local_settings you can override anything in settings, but
local_settings can't tell what settings are. I sometimes want to
conditionally override things so using base_settings (with all the
defaults) and then importing it into local_settings at the top allows
me to access as well as override the defaults. It also makes it easy
to run different configurations like:

./manage.py runserver --settings=settings_one

> With all of that said, I'm now poised to ask my question :)
> We need to activate the "activate_this.py" script to activate the virtual
> env environment. This is done with this snippet of code, directly from the
> virtualenv documentation:
> activate_this = '/path/to/env/bin/activate_this.py'
> execfile(activate_this, dict(__file__=activate_this))

Actually I'd say don't do this. The environment shouldn't be
hard-coded into the settings file imo. If you are deploying via wsgi
use wsgi's support of virtualenvs to specify the environment - and
really from the python execution perspective all you really need to
support a virtualenv is to put the site-packages dir of the env on
your sys.path. However you achieve it I'd tend not to use the
"activate_this" method in your settings file. On your local box you
can use "workon mytest-env" or source mytest-env/bin/activate if you
don't have Hellman's virtualenvwrapper installed. Your test and
production environment should be specified as part of your server
specific deployment - in a virtualhost.conf or in a app.wsgi file if
at all possible. This gets away from the "double activation" issue you
reference which I have to admit I haven't specifically tried. :)

> As a side note, I wish Django had more of a concept of different
> 'environments' so this could be managed without feeling as if we're
> "hacking" into Django sometimes.

Bingo - I think that's a clue that Python runtimes and execution
environments shouldn't be managed at the level of your django project.
In fact the linkage should go the other way - environments manage
python apps. A common case would be switching environments to get you
different versions of your app - or django project in this case - and
this sort of fluidity is harder to script and build if the app wants
to specify by name what environment it lives in.

I hope that helps - I know I'm not answering your original question :)

Simeon Franklin

More information about the Baypiggies mailing list