On Wed, May 22, 2013 at 12:41 PM, Charles Mulder <charlesmur...@gmail.com>wrote:
> Hi, > > Hope you're well. > > I've added a couple of environment variables to my virtualenv postactivate > file, for example: > > export DATABASE_USER="root" > export DATABASE_PASSWORD="12345678" > N.B. that environment variables are not as secure as you might hope (though certainly better than passwords on the command line). > > I then assign those variables in my settings.py using > os.environ['DATABASE_USER'], for example > > DATABASE_USER = os.environ['DATABASE_USER'] > > Since my Apache virtualhost file contains > > WSGIDaemonProcess mysite.local > python-path=/my/python/path:/path/to/my/project/venv/lib/python2.7/site-packages > If memory serves, this does not cause the .pth files in site-packages to be applied. Could be OK. Could be a problem. If you have only one wsgi script on that Apache, you might consider the WSGIPythonHome directive (the directive must be global, rather than in a vhost, thus there can be only one). Or, if you have a new enough mod_wsgi, the WSGIDaemonProcess directive also takes a "python-home" argument (I do have three or four ve's running on one Apache this way). There are some restrictions as to other configuration stuff, but the defaults work for me. Otherwise you need to play with sys.path in your wsgi script, or at least invoke site.addsitedir() correctly, see: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments WSGIProcessGroup mysite.local > WSGIScriptAlias / /path/to/my/project/wsgi.py > This wouldn't be the wsgi.py created by manage.py startproject, would it? It's necessary these days for manag.py runserver, but I've yet to find it adequate to use with mod_wsgi. (I must confess that I haven't played with it for at least 6 months.) It's not too hard to write your own, taking all the path manipulations, that runserver doesn't need but mod_wsgi does, into account. > > As I understand it, this tells mod_wsgi to run in daemon mode and which > virtualenv to use. > Since it knows which virtualenv to use, I would image it would run > postactivate, thereby enabling my environment variables, but this however > is not the case. > mod_wsgi does not "activate" the virtualenv. You will have to find somewhere else to add environment variables. Maybe in some Apache config file, but more likely in your wsgi script. The only truly useful thing that activate normally does is to put the directory containing the venv's python early on the shell path. If you run: /absolute/path/to/ve/bin/python manage.py runserver It will work just fine (for folks who don't depend on other actions like setting environment variables in postactivate). You can use *nix's cmp command to confirm that the python is an unmodified of the(a) system python. The whole trick to virtualenv is that, if the PYTHONHOME environment variable isn't set. python uses the location of the executable file to figure out where the correct lib/pythonX.X directory is. > Am I doing something wrong? Any suggestions or recommendations are > welcome. > > Kind regards, > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
