pipenv prefers activated virtualenvs when looking for projects

[jxltom]

Issue description

pipenv shell can not activate custom virtualenv created by virtualenv

Actual result

➜  abcd  . /Users/jxltom/.local/share/virtualenvs/abcd-Gj3qkKPD/bin/activate
.: no such file or directory: /Users/liujunxiao/.local/share/virtualenvs/abcd-Gj3qkKPD/bin/activate

Steps to replicate

• virtualenv somedir
• cd somedir && source bin/activate
• pipenv shell

---

Please run $ pipenv --support, and paste the results here. Don't put backticks (`) around it! The output already contains Markdown formatting.

If you're on macOS, run the following:

$ pipenv --support | pbcopy

If you're on Windows, run the following:

> pipenv --support | clip

If you're on Linux, run the following:

$ pipenv --support | xclip

[frostming]

I am curious about your workflow. Why do you pipenv shell after the virtualenv is already activated?

I don't think this is a problem

[jxltom]

I'm not using this workflow. But pipenv shouldn't raise error even in this case. Maybe users don't know they are already in a virtualenv and try to run pipenv shell. The pipenv should still activate virtualenv successfully instead of trying to activate an non-existed virtualenv.

Actually one user case is that users may already in an activated virtualenv such as activated by vscode automatically, but pipenv shell could help re-activating this virtualenv with .env loaded.

[frostming]

Plus, did this really work in earlier versions? I wrote #3243 but as far as I can tell it didn't change the way virtualenv location is detected, but enabled pipenv to set VIRTUAL_ENV on the run while keeping track of the virtualenv_location. Correct me if i am wrong.

[jxltom]

Actually virtualenv_location is changed by setting PIPENV_ACTIVATE since virtualenv_location is a property which is calculated during calling. Setup PIPENV_ACTIVE will change its value. So passing virtualenv_location to fork_args must happen before setup PIPENV_ACTIVATE otherwise wrong location will be passed into shell

[jxltom]

Besides, I can confirm it works for versions before 2018.11.14 (included) 😄

[frostming]

Yes, i didn't think that through.

[techalchemy]

Was this an issue only for shell, I assume? Not for run? I was a bit skeptical of the changes to is_in_virtualenv having unintended consequences like this but the code too hard to reason about anyway, so I figured it was worth merging.

[frostming]

pipenv run is already in the test suite. So i'm okay with it.

[jxltom]

@techalchemy Oh, thanks for reminding. It also effects pipenv run and I missed that. I've updated the PR.

Step to reproce:

• virtualenv abc
• cd abc && source bin/activate
• pipenv run which pip. It will show as below. Actually a new virtuanlenv is created by pipenv located at /home/jxltom/.local/share/virtualenvs/abc-HoOUeXpF though pipenv is already in a activated virtualenv. This is because inline_activate_virtual_environment is reading virtualenv_location and after setup PIPENV_ACTIVE, value of virtualenv_location is changed and thus incorrect path is being used. We shoud set PIPENV_ACTIVE after inline_activate_virtual_environment

(abc) ➜  abc pipenv run which pip
/home/jxltom/.local/share/virtualenvs/abc-HoOUeXpF/bin/pip

And it should be:

(abc) ➜  abc pipenv run which pip
/home/jxltom/Desktop/abc/bin/pip

[techalchemy]

I updated your issue title, I'm really trying to get at the heart of what the issue is that you're reporting here because I'm still not really sure it's a problem...

PIPENV_IGNORE_VIRTUALENVS is specifically designed so that if you are in an activated virtualenv, pipenv doesn't use it and prefers its own...

This doesnt effect pipenv run or pipenv shell, (arguably it should effect `pipenv run so that might be the bug)?