Conflicts with Python virtualenv due to same name of environment variable

[djbclark]

$ source .virtphp/envs/php5/bin/activate
You are currently running a virtualenv session: /home/username/local/python/3
Please exit this session before starting a virtPHP session.

It looks like it's because it searches for this env variable in the actuvate scriptL
if [ "$VIRTUAL_ENV" ] ; then

Changing that to PHP_VIRTUAL_ENV seems to have fixed the problem, did a quick look and didn't find that used anywhere else.

[jakerella]

Ouch... good catch! You can tell we're not Python devs. ;)

@ramsey @jwoodcock Thoughts on switching to $PHP_VIRTUAL_ENV? I'm fine with it.

[jwoodcock]

This is actually on purpose. To insure we don't have any collisions with python, we put this test in to prevent a user from activating a virtPHP env while they were in an active Python virtualenv. We did this because we were concerned that virtualenv is doing something, or would be doing something that we would create a conflict between both tools.

[jakerella]

Hmm... is this a case of premature optimization maybe? I mean, do we know that there is some conflict?

[ramsey]

The primary conflict is the deactivate command. If you are in a Python virtualenv environment and then you activate a virtPHP environment, we replace the deactivate command with our own by the same name. So, you are no longer able to deactivate your virtualenv environment, and it's unclear what you intend to do when you call deactivate.

I suppose we could give our deactivate command a different name. We'd also need to comb around and make sure we don't have any other conflicts.

[jakerella]

Ugh... As much as I don't want to have deativate-virtphp as the command, I can see the potential for someone to have an active Python and PHP virtual environment at the same time. I suppose we could detect if there is already a deactivate command, then use a php-sepcific command name. Or we could grab it's "real" location, store that somewhere, then warn the user that if they call deactivate we'll deactivate both environments.

None of these sound like desirable solutions though.

[jwoodcock]

I think the current solution is the best solution and vote for keeping it. But I'm always open to good reason for changing it, though none listed are what I would consider good. The thought of a dev using both python and php at the same time is so fringe, especially if you include this is all based on the current terminal session. So if I wanted both python and php going without this conflict, all I have to do is open another terminal session.

[jakerella]

Well, if they're calling a python script from within php then opening another terminal session wouldn't solve the problem. But I agree that it is a fringe use case. Perhaps we can just put a warning in the README and maybe in that error message when we detect an existing virtual env?

[jwoodcock]

So this warning isn't enough? ;)

"You are currently running a virtualenv session: /home/username/local/python/3"

[jwoodcock]

@djbclark So when you hit this message, were you needing both the Python virtualenv and virtPHP env running at the same time?

[ramsey]

Let's keep this open for a bit. I'm working on a PHP Twig extension that uses Python's Pygments library. I'll try using virtPHP together with virtualenv to see how things go. My suspicion is that PHP is unaware of the current terminal session, so even if a virtualenv environment is active, it's not going to use the pygmentize that is installed in that environment because it has no access to the current shell's $PATH.

Just a hypothesis for now. I'll test it.

[ghost]

why the hell we want to virtuals env on the same terminal?