[Baypiggies] VirtualEnv and Django question

[Eric Walstad]

Forgot to send to the list, too.
EW

On Wed, Feb 23, 2011 at 7:08 PM, Eric Walstad <eric at ericwalstad.com> wrote:
> Hey Glen
>
> What's worked well for us is to have a base settings file
> (settings_base.py) which contains the common settings.  Then at the
> top of settings_stage.py, settings_prod.py, settings_ew.py, etc,
> there's a
> from settings_base import *
>
> Doing it this way puts all the common settings into the current
> context, something you don't get when you put the import at the bottom
> of the file.  That's handy when you want to, say, add an installed app
> like django debug toolbar into your development workstation's settings
> file.  The production environment would use
> DJANGO_SETTINGS_MODULE=projectname.settings_prod, staging would use
> DJANGO_SETTINGS_MODULE=projectname.settings_stage, etc.  The
> settings_base.py would not be used directly.
>
> Also, have you played with the excellent virtualenvwrapper, by Dough
> Hellman?  You get a 'workon' script (workon myvirtualenv) that
> activates your virtualenv as well as a postactivate scritpt that is
> called after virtualenv activation.  I typically use the postactivate
> script to setup my DJANGO_SETTINGS_MODULE and other project specifics.
>  Virtualenvwrapper has many other helper scripts.  I recommend it.
>
> Best regards,
>
> Eric.
>
> 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