Closed GoogleCodeExporter closed 9 years ago
Secondly, when using the daemon mode of mod_wsgi 2.0+ custom environment
variables
are not preserved. For example, setting a process environment variable with
SetEnv to
select the application's profile or environment (i.e. development, production,
testing) is impossible without using a wrapper script when running in daemon
mode.
Perhaps even a parameter to WSGIDaemonProcess like:
WSGIDaemonProcess myprocess ... setenv=ENV=development
.. or similar.
Is there a way of doing this per application/script? I haven't really looked
into it
in enough detail.
Original comment by samuel.c...@gmail.com
on 3 Nov 2008 at 7:28
SetEnv isn't doing what you expect because this isn't CGI.
The original purpose of SetEnv for CGI was to set process environment
variables. With mod_wsgi, they only serve
to set variables in the WSGI environ dictionary which is passed to the WSGI
application as an argument.
The moral of the story is that you should not be relying on process environment
variables in WSGI applications, it
is bad practice and can actually cause lots of problems in a multithreaded
application. Unfortunately, some Python
web frameworks carry over this practice.
Suggest you take this discussion over to mod_wsgi list on Google groups and we
can discuss there what it is you
are actually trying to achieve.
Original comment by Graham.Dumpleton@gmail.com
on 3 Nov 2008 at 9:50
Decided that don't want to have mod_wsgi specific directives for setting a
second set of variables to be later
integrated into WSGI environment as it just gets too messy.
Certainly, what variables are passed shouldn't be derived from a specific URL
context from SetEnv directives
or similar. If it is desired that configuration variables be able to be passed
from Apache configuration for a
specific authnz hook, then they perhaps should be an option that can be
supplied to the directive which sets
up the hook to do it and not a separate directive.
Original comment by Graham.Dumpleton@gmail.com
on 12 Mar 2009 at 5:11
Original issue reported on code.google.com by
Graham.Dumpleton@gmail.com
on 28 Mar 2008 at 11:14