[Baypiggies] VirtualEnv and Django question

Elizabeth Leddy elizabeth.leddy at gmail.com
Thu Feb 24 03:15:57 CET 2011


Hi Glen -

I don't *think* there should be any consequences for doing that but until
someone has a more thoughtful answer... Have you considered buildout? I use
buildout for all of my python projects now (including Django) and then I use
a different cfg for dev and production. While I'm sure there are people who
will argue against this (please do!) I have stopped using virtualenv
entirely in exchange for buildout (version 1.5 and up). You can use them
together to be safe of course but I found it wasn't needed.

Liz

On Wed, Feb 23, 2011 at 6:07 PM, Glen Jarvis <glen at glenjarvis.com> wrote:

> I have been managing several environments that have Django. I'm using
> virtualenv and pip and have a question about using activate_this.py twice
> (one environment "overriding" the other).
>
> However, I have to give some background so you understand why I'm asking:
>
> We use Django, and have our settings.py file stored in a repository.
> However, as there are different environments that this is used in, some
> people would need to make changes to their settings file. 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):
>
> # LOCAL SETTINGS
> #############################################################
> # Do not change/move the following line. Instead, see the comments in
> # example_local_settings.py
>
> ###############################################################################
> from local_settings import *
>
>
> And then, a local_settings.py file would redefine (and overwrite) any
> settings that were customized for the environment. The local_settings.py
> file is not checked into the repository (in fact, it's svn:ignore'd).
>
> So, for example, if I wanted to do some experimenting and checked out a
> fresh copy of the repository, I would want to tell django to use my
> TEMPLATE_DIRS instead of the default ones, I may do something like this in
> my local_settings.py file:
>
> TEMPLATE_DIRS = (
>     '/home/glenjarvis/some/path/to/freshly/checked/out/templates',
> )
>
> Then, Django would work for my local environment without touching the
> original settings.py file. I wouldn't have to change any file that is in the
> repository (except maybe for the templates in question) and I wouldn't
> accidentally overwrite the settings.py file and have it accidentally make it
> into production.
>
> 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))
>
>
> We typically leave the settings as they would be in production, and
> overwrite them in our testing, local development and other environments. So,
> I have written this in the top of the Django settings.py file (so it is sete
> in production):
>
> I would do something like this:
>
> # Activate with virtualenv first
> ENVIRONMENT = 'production'
> activate_this = '/path/to/our/software/envs/base/%s/bin/activate_this.py'
> % ENVIRONMENT
> execfile(activate_this, dict(__file__=activate_this))
>
> To override this, I would typically have the following in my local
> settings.py file:
>
> ENVIRONMENT = 'glens_example_test_3'
> activate_this = '/path/to/our/software/envs/base/%s/bin/activate_this.py'
> % ENVIRONMENT
> execfile(activate_this, dict(__file__=activate_this))
>
> My questions are the consequences of "activating" a virtualenv when another
> is already activated. I would like to be safe and do the equivalent of
> "deactivate" (as we do with shell virtual environments), before activating
> this again for any special cases where we override the original. Again, we
> don't want to change our  main settings.py file unless it really is a
> production environment change.
>
> BTW, I don't see any immediate errors, but I want to be certain that there
> are no hidden "gotchas" for down the road....
>
> As an alternate approach, we could set ENVIRONMENT and activate_this
> variables in the settings (over-writing as above), but only do the following
> in manage.py:
>
> ....
> if __name__ == "__main__":
>     execute_manager(settings)
>     execfile(activate_this, dict(__file__=settings.activate_this))
>
>
> However, I don't remember if manage.py is used at all by mod_wsgi or
> mod_python.
>
> 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.
>
> Simeon or anyone on BayPIGgies, have you seen this situation before? Is it
> safe to just activate_this twice with a different environment than the
> original? Where in Django do you incorporate your establishment for
> virtualenv?
>
>
> Thanks in advance,
>
>
>
> Cheers,
>
>
>
> Glen
> --
> Things which matter most must never be at the mercy of things which matter
> least.
>
> -- Goethe
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20110223/3732b568/attachment-0001.html>


More information about the Baypiggies mailing list