Simeon and Eric,<div><br><div> 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:</div>
<div><br></div><div>+- manage.py</div><div>+- settings</div><div>+----- __init__.py</div><div>+----- base.py (or possibly common.py)</div><div>+----- production.py</div><div>+----- test.py</div><div>etc.</div><div><br></div>
<div>referred to by projectname.settings.test or projectname.settings.production etc... </div><div><br></div><div>Regardless, I can see how you avoided this situation altogether.</div><div><br></div><div>Everyone else,</div>
<div> 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).</div>
<div><br></div><div> 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</div>
<div><br></div><div> 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.</div>
<div><br></div><div> 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.</div>
<div><br></div><div> 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.</div>
<div><br></div><div>> I hope that helps - I know I'm not answering your original question :)</div><meta charset="utf-8"><div><br></div><div>absolutely! It helped me know how you approached this problem -- avoiding my situation all together...</div>
<div><br></div><div>Thank you! :)</div><div><br></div><div><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 7:50 AM, Simeon Franklin <span dir="ltr"><<a href="mailto:simeonf@gmail.com">simeonf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Feb 23, 2011 at 6:07 PM, Glen Jarvis <<a href="mailto:glen@glenjarvis.com">glen@glenjarvis.com</a>> wrote:<br>
</div><div class="im">>To keep this clean<br>
> so there can be customized fields, we did this.<br>
> In the settings.py file (that is in the repository), we have the following<br>
> line (at the very bottom of the file):<br>
> # LOCAL SETTINGS<br>
</div>> from local_settings import *<br>
<br>
I think Eric Walstad already explained this but I do find the reverse<br>
pattern more flexible. If at the bottom of settings you import<br>
local_settings you can override anything in settings, but<br>
local_settings can't tell what settings are. I sometimes want to<br>
conditionally override things so using base_settings (with all the<br>
defaults) and then importing it into local_settings at the top allows<br>
me to access as well as override the defaults. It also makes it easy<br>
to run different configurations like:<br>
<br>
./manage.py runserver --settings=settings_one<br>
<div class="im"><br>
> With all of that said, I'm now poised to ask my question :)<br>
> We need to activate the "activate_this.py" script to activate the virtual<br>
> env environment. This is done with this snippet of code, directly from the<br>
> virtualenv documentation:<br>
><br>
> activate_this = '/path/to/env/bin/activate_this.py'<br>
> execfile(activate_this, dict(__file__=activate_this))<br>
<br>
</div>Actually I'd say don't do this. The environment shouldn't be<br>
hard-coded into the settings file imo. If you are deploying via wsgi<br>
use wsgi's support of virtualenvs to specify the environment - and<br>
really from the python execution perspective all you really need to<br>
support a virtualenv is to put the site-packages dir of the env on<br>
your sys.path. However you achieve it I'd tend not to use the<br>
"activate_this" method in your settings file. On your local box you<br>
can use "workon mytest-env" or source mytest-env/bin/activate if you<br>
don't have Hellman's virtualenvwrapper installed. Your test and<br>
production environment should be specified as part of your server<br>
specific deployment - in a virtualhost.conf or in a app.wsgi file if<br>
at all possible. This gets away from the "double activation" issue you<br>
reference which I have to admit I haven't specifically tried. :)<br>
<div class="im"><br>
> As a side note, I wish Django had more of a concept of different<br>
> 'environments' so this could be managed without feeling as if we're<br>
> "hacking" into Django sometimes.<br>
<br>
</div>Bingo - I think that's a clue that Python runtimes and execution<br>
environments shouldn't be managed at the level of your django project.<br>
In fact the linkage should go the other way - environments manage<br>
python apps. A common case would be switching environments to get you<br>
different versions of your app - or django project in this case - and<br>
this sort of fluidity is harder to script and build if the app wants<br>
to specify by name what environment it lives in.<br>
<br>
I hope that helps - I know I'm not answering your original question :)<br>
<br>
-regards<br>
<font color="#888888">Simeon Franklin<br>
</font></blockquote></div><br><br clear="all"><br>-- <br><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Things which matter most must never be at the mercy of things which matter least.</span><br>
<br>-- Goethe <br>
</div></div>