--site-packages does not seem to be respected after 2018.7.1.

[Marviel]

Issue description

When upgrading from 2018.7.1 -> 2018.11.26, we noticed an inconsistency in our automated builds regarding a few packages which were installed at site packages and were being pulled in via the --site-packages flag.

The following docker command fails with an import exception when the python command is run. Note that requests is being installed at site packages and not in the Pipfile, intentionally.

Docker Command 1 (Fails)

docker run -w "/root/" -it python:2 bash -c "pip install requests && pip install --upgrade pipenv==2018.11.26 && pipenv --site-packages run python -c 'import requests; print(requests.__version__)'"

Expected result

When I run the identical command (using the older version of pipenv):

Docker Command 2 (Succeeds)

docker run -w "/root/" -it python:2 bash -c "pip install requests && pip install --upgrade pipenv==2018.7.1 && pipenv --site-packages run python -c 'import requests;print(requests.__version__);'"

produces the expected output:

.
.
[... long output omitted ... ]
.
.
Creating a virtualenv for this project...
Pipfile: /root/Pipfile
Using /usr/local/bin/python (2.7.15) to create virtualenv...
⠋Already using interpreter /usr/local/bin/python
New python executable in /root/.local/share/virtualenvs/root-BuDEOXnJ/bin/python
Installing setuptools, pip, wheel...
done.
Setting project for root-BuDEOXnJ to /root

Making site-packages available...
Virtualenv location: /root/.local/share/virtualenvs/root-BuDEOXnJ
2.21.0

Actual result (from Docker Command 1)

.
.
[... long output omitted ... ]
.
.
Creating a virtualenv for this project...
Pipfile: /root/Pipfile
Using /usr/local/bin/python (2.7.15) to create virtualenv...
⠸ Creating virtual environment...Already using interpreter /usr/local/bin/python
New python executable in /root/.local/share/virtualenvs/root-BuDEOXnJ/bin/python
Installing setuptools, pip, wheel...
done.

✔ Successfully created virtual environment!
Virtualenv location: /root/.local/share/virtualenvs/root-BuDEOXnJ
Creating a Pipfile for this project...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named requests

Steps to replicate

1. Run Docker Command 1, listed above.

Other Information

• I ran this test for several different versions -- it appears the behavior cropped up after 2018.10.9, leading me to speculate it has to do with the changes introduced in: Always use virtualenv directly, not "pew new" #2518.
• Ran identical tests with the python:3 docker image, with essentially the same results
• I found it interesting to note that the failing command does not include the phrase Making site-packages available... that the successful command does.

---

$ pipenv --support

Pipenv version: '2018.11.26'

Pipenv location: '/usr/local/lib/python2.7/site-packages/pipenv'

Python location: '/usr/local/bin/python'

Python installations found:

• 3.5.3: /usr/bin/python3.5
• 3.5.3: /usr/bin/python3.5m
• 2.7.15: /usr/local/bin/python
• 2.7.13: /usr/bin/python2.7

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.9.125-linuxkit',
 'platform_system': 'Linux',
 'platform_version': '#1 SMP Fri Sep 7 08:20:28 UTC 2018',
 'python_full_version': '2.7.15',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

System environment variables:

• LANG
• PYTHONIOENCODING
• TERM
• GPG_KEY
• PYTHON_VERSION
• PIP_DISABLE_PIP_VERSION_CHECK
• SHLVL
• PYTHON_PIP_VERSION
• HOSTNAME
• PYTHONDONTWRITEBYTECODE
• PWD
• PIP_SHIMS_BASE_MODULE
• PATH
• PYTHONFINDER_IGNORE_UNSUPPORTED
• HOME
• PIP_PYTHON_PATH
• _

Pipenv–specific environment variables:

Debug–specific environment variables:

• PATH: /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
• LANG: C.UTF-8
• PWD: /root

---

[n-batalha]

Same here.

For those needing a workaround with the current version (2018.11.26), somehow starting a virtualenv with pipenv --site-packages --three (and only after pipenv install) works (instead of using pipenv --site-packages install from pipfile to start the environment).

[frostming]

@Marviel @n-batalha Can you try against the master branch to confirm if it still exists?

[techalchemy]

I believe this is resolved on master as of #3836, closing now. Do let us know if this persists in the next release