[Baypiggies] VirtualEnv and Django question

[Glen Jarvis]

Simeon and Eric,

   Thank you for explaining the way you organize your settings. I like it
*much* more than what I currently implemented. We'll still have to have a
private "local_settings.py" for the developers to play in (as we can't have
a different settings file for each of them). In fact, although this hasn't
been testing, I really like having a settings directory with the following
contents:

+- manage.py
+- settings
+----- __init__.py
+----- base.py (or possibly common.py)
+----- production.py
+----- test.py
etc.

referred to by projectname.settings.test or projectname.settings.production
etc...

Regardless, I can see how you avoided this situation altogether.

Everyone else,
   Thank you! :)  I always learn a lot from asking questions here. Using the
command line and our environment's works perfectly -- I have some wrapper
scripts that activates environments. However, there's a problem I'm trying
to solve -- I can't "activate" the same environment in the Apache
configuration file (or I don't seem to be successful in doing so).

    We don't have controller over our apache web server and the python
modules. We also have mod_python (I hadn't yet been able to migrate to
mod_wsgi, but am working on that after I fix this problem.. I'm working
incrementally). Also, we are fixed at python2.4

     The problem is that using SetEnv to set the PATH,
DJANGO_SETTINGS_MODULE, PATH and the PythonPath in the apache conf.d/config
file (which we do have control over), doesn't "seem to have the same
environment" as using the virtualenv/activate. Even though I took those
variables directly from the environment of an 'activated' environment.
Packages are found successfully in the 'activated' environment, but not from
the webserver. I even set VIRTUAL_ENV with the same result (I don't know
it's significance and if it's needed). We are also frozen at Python 2.4 in
the webserver and I seem to have more problems with 2.4 than I did with 2.7.

    Simeon, I agree 100% that this should be environment based only. In
fact, I'm glad you sent me that reminder or I may have kept "plodding along"
instead of stopping, taking a break and thinking of the best way to handle
this.

    I'm going to research some more on the 'acton' answers I've gotten (I
don't know how the 'acton' scripts differ from the virtualenv's
'bin/activate' scripts). I also need to remind myself to take this in small
steps that can be rolled back so I don't get myself into a pickle here with
a production environment.

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

absolutely! It helped me know how you approached this problem -- avoiding my
situation all together...

Thank you! :)


On Thu, Feb 24, 2011 at 7:50 AM, Simeon Franklin <simeonf at gmail.com> wrote:

> 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):
> > # LOCAL SETTINGS
> > 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 :)
>
> -regards
> Simeon Franklin
>



-- 
Things which matter most must never be at the mercy of things which matter
least.

-- Goethe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20110224/b40974e5/attachment-0001.html>