Joshua Bronson wrote:
> I just worked on this with Doug. We were seeing one thing when starting
> dev.livablestreets.com's opencore in foreground and another when starting it
> with supervisor. We traced this into the following section of
> fassembler.configparser.get_config:
> 
>     env = os.environ['VIRTUAL_ENV']
>     env_name, env_path = (os.path.basename(env), os.path.dirname(env))
> 
>     if ini_path is None:
>         ini_path = os.sep.join([env_path, 'etc', 'build.ini'])
> 
> In the zopectl fg case, env was of course correctly set to
> /usr/local/topp/dev.livablestreets.com/builds/20080320/opencore, as we had
> source bin activated manually. On the other hand, in the supervisorctl start
> opencore case, os.environ['VIRTUAL_ENV'] was set to
> /usr/local/topp/dev.livablestreets.com/builds/20080313/opencore, the previous
> week's build. But that's funny: As you say, before r14626, bin/start-opencore
> never activated any environment. We suspect that whoever started the
> supervisord process that was running had started it from an activated
> environment in the previous week's opencore directory, so it was inheriting
> the wrong value. Sure enough, when we ran supervisorctl shutdown and
> supervisorctl restart all, os.environ['VIRTUAL_ENV'] was now set to None.
> Hence r14626, which sets it correctly.
> 
> Are there any more plausible theories?

Yes, if you did supervisorctl shutdown that would stop the daemon, and 
the next time it restarted it could have a different environment.  I 
thought supervisor would have a setting to clear the environment so that 
we couldn't accidentally depend on it this way.  But apparently not.

You can however set environmental variables in the supervisor.d/* files, 
like:

environment = VIRTUAL_ENV={{base}}/opencore

Maybe we should do that, which would alleviate the need for both 
activate and make sure we don't inherit at least this one setting.  We 
could do that for all projects globally, instead of just opencore.

We could override other settings as well, e.g., PATH, if we want to be 
extra careful not to depend on the containing environment.  Or we could 
change the bin/supervisord script to clear the environment.

   Ian