pipenv installs into python installation and not virtualenv

[m-stolle]

Issue description

pipenv install installs packages like pytest into PYTHONHOME Location and not the virtualenv

Expected result

pytest is installed into virtualenv and pipenv run pytest works.

Actual result

Installing collected packages: pytest The scripts py.test.exe and pytest.exe are installed in 'D:\Python36\Scripts' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. Successfully installed pytest-4.0.0.

pipenv run pytest results in command pytest not found

Steps to replicate

$ pipenv --support

Pipenv version: '2018.11.14'

Pipenv location: 'd:\\python36\\lib\\site-packages\\pipenv'

Python location: 'd:\\python36\\python.exe'

Python installations found:

• 3.6.7: D:\Python36\python.exe
• 3.6.6: D:\Python36-64\python.exe

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.6.7',
 'os_name': 'nt',
 'platform_machine': 'AMD64',
 'platform_python_implementation': 'CPython',
 'platform_release': '7',
 'platform_system': 'Windows',
 'platform_version': '6.1.7601',
 'python_full_version': '3.6.7',
 'python_version': '3.6',
 'sys_platform': 'win32'}

System environment variables:

• ALLUSERSPROFILE
• APPDATA
• CGROAMINGPATH
• CLIENTNAME
• COMMONPROGRAMFILES
• COMMONPROGRAMFILES(X86)
• COMMONPROGRAMW6432
• COMPUTERNAME
• COMSPEC
• DAS_HOME
• DSPACE_RTT_TOOLS_2
• FP_NO_HOST_CHECK
• GOPATH
• GOROOT
• HOMEDRIVE
• HOMEPATH
• HTTPS_PROXY
• LM_LICENSE_FILE
• LOCALAPPDATA
• LOGONSERVER
• LSFORCEHOST
• LSHOST
• NUMBER_OF_PROCESSORS
• OPENSSL_CONF
• OS
• PATH
• PATHEXT
• PLMVIS_82_LIBPATH
• PROCESSOR_ARCHITECTURE
• PROCESSOR_ARCHITEW6432
• PROCESSOR_IDENTIFIER
• PROCESSOR_LEVEL
• PROCESSOR_REVISION
• PROGRAMDATA
• PROGRAMFILES
• PROGRAMFILES(X86)
• PROGRAMW6432
• PROMPT
• PSMODULEPATH
• PUBLIC
• RTARCH
• RTHOME
• SECSPECIALMODE
• SESSIONNAME
• SILVER_HOME
• SIL_USER_TYPE
• SYSTEMDRIVE
• SYSTEMROOT
• TEMP
• TERM
• TMP
• TSK_OPTIONS_FILE_SW160800V6_2R1
• UATDATA
• USERDNSDOMAIN
• USERDOMAIN
• USERDOMAIN_ROAMINGPROFILE
• USERNAME
• USERPROFILE
• VS100COMNTOOLS
• VS120COMNTOOLS
• VS140COMNTOOLS
• VS90COMNTOOLS
• WINDIR
• WINDOWS_TRACING_FLAGS
• WINDOWS_TRACING_LOGFILE
• PIP_DISABLE_PIP_VERSION_CHECK
• PYTHONDONTWRITEBYTECODE
• PIP_SHIMS_BASE_MODULE
• PIP_PYTHON_PATH
• PYTHONFINDER_IGNORE_UNSUPPORTED
• PYTHONHOME

Pipenv specific environment variables:

Debug specific environment variables:

• PATH: C:\Program Files (x86)\Common Files\Oracle\Java\javapath;%PYTHONHOME%;%PYTHONHOME%\Scripts;D:\Sprachen\Perl\perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;l

[duplicate-issues]

Hey @m-stolle,

We did a quick check and this issue looks very darn similar to

• #3260 - PipfileNotFound raised for no Pipfile while installing
• #3259 - Update pythonfinder for resilient parsing
• #3255 - Installation failed due to missing hashes when using --skip-lock

This could be a coincidence, but if any of these issues solves your problem then I did a good job 😄

If not, the maintainers will get to this issue shortly.

Cheers,
Your Friendly Neighborhood ProBot

[techalchemy]

I believe this is fixed on the master branch — @frostming is this covered by your change to environment targets?

[techalchemy]

Also can you provide the text of the command you executed and the content of your Pipfile

[m-stolle]

Sure,

Pipefile

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
pyparsing = "*"
pytest = "*"
pytest-mock = "*"
pytest-pythonpath = "*"
pylint = "*"

[dev-packages]

[requires]
python_version = "3.6"

Command:
D:\Python36\scripts\pipenv.exe install -v --python D:\Python36\python.exe

pip_output.txt

[frostming]

I guess this line can explain the issue.

PYTHONHOME is set. You *must* activate the virtualenv before using it

@m-stolle pip will install site packages to PYTHONHOME. You should unset it and Python interpreter will still be working well.

[frostming]

I compared the behavior with virtualenv.

@techalchemy When PYTHONHOME is set, using $(VENV_PATH)/bin/pip install ... won't do the trick. Maybe we should shade the PYTHONHOME temporarily inside virtualenv, shell, run, etc.?

[techalchemy]

I'm not totally certain whats best here, my initial instinct was yeah to just unset it the way we do with PIP_USER -- just check if allow_global or system is set, and if not, just unset PYTHONHOME? I might override it in pipenv.environment.Environment.activated() anyway...