-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pipenv run in the same directory from cmd.exe and bash (git for windows) use different virtualenvs #2857
Comments
As a note, I'll point out that vscode allows the user to choose shells and Microsoft feels any of cmd.exe, PowerShell, Git Bash and Bash on Ubuntu are reasonable choices for a shell, thus it seems reasonable to expect all of these shells (with the possible exception of Bash on Ubuntu) should choose the same name and path for the virtualenv if the shells all have the same |
Do you have |
Ah, wait no, I take that back. |
Aha! Very astute! So I found there was a case discrepancy in what git for windows Bad:
Works:
seen side by side with HOME set as /c/Users and not /c/users, the proper virtualenv is seen. Seems that both cmd.exe and git for windows bash seem to be case insensitive with regards to directory names and cd? I don't know if that's something that pipenv on windows could or should check for, or warn about, but thank you for your help! |
I’m both happy and sad I guessed right :) Path casing on Windows is particularly difficult to get right, and we certainly didn’t do it right from the beginning, and unfortunately it is difficult to fix now (without breaking backward compatibility and making everyone angry, at least). I believe we made some changes recently to improve the situation, but I am not sure whether this is included. I’ll test this a bit and see if it is possible. |
@uranusjr An addendum. The same problem (but worse?), or perhaps a different problem, but could you take a look at this? Going back to basics, when I "correctly" set the This takes place in a mingw shell with no dot files being run....
|
oh windows. This is what happens when we normalize things. Posix is case sensitive so we can't follow normalization rules like we do for win32, we need to figure out what the normalized win32 path would be and see if the corresponding virtualenv exists first |
The path case issue is settled in #3105 , but I guess the problem here is the path under cmd.exe differs from that of bash.exe. Please try |
This is no longer an issue on the master branch.
Git shell:
|
Issue description
On a Windows 10 machine, I have
Using
cmd.exe
I thenpipenv shell
And I watch as a virtualenv is created in
~.virtualenvs
with the modules specified in the Pipfile.Then using
bash.exe
fromgit for windows
, Ipipenv shell
And I watch as a new and different virtualenv is created in
~.virtualenvs
Expected result
I would have expected pipenv run within bash of git for windows to use the virtualenv created by pipenv run within cmd.exe. (Note, powershell, and vscode all use the virtualenv created in the cmd.exe shell)
Actual result
Two different virtualenvs are created
Steps to replicate
Follow the steps above
Please run
$ pipenv --support
, and paste the results here. Don't put backticks (`
) around it! The output already contains Markdown formatting.C:\Users\jerry\d\udemy\projects-in-django>pipenv --support
$ pipenv --support
Pipenv version:
'2018.7.1'
Pipenv location:
'C:\\Users\\jerry\\AppData\\Roaming\\Python\\Python37\\site-packages\\pipenv'
Python location:
'c:\\python\\python37\\python.exe'
Other Python installations in
PATH
:3.7
:C:\Python\Python37\python.exe
3.7.0
:C:\Python\Python37\python.exe
3.7.0
:C:\Windows\py.exe
PEP 508 Information:
System environment variables:
ALLUSERSPROFILE
APPDATA
COMMONPROGRAMFILES
COMMONPROGRAMFILES(X86)
COMMONPROGRAMW6432
COMPOSE_CONVERT_WINDOWS_PATHS
COMPUTERNAME
COMSPEC
DOCKER_CERT_PATH
DOCKER_HOST
DOCKER_MACHINE_NAME
DOCKER_TLS_VERIFY
DOCKER_TOOLBOX_INSTALL_PATH
DRIVERDATA
FPS_BROWSER_APP_PROFILE_STRING
FPS_BROWSER_USER_PROFILE_STRING
HOME
HOMEDRIVE
HOMEPATH
LOCALAPPDATA
LOGONSERVER
MOZ_PLUGIN_PATH
NO_PROXY
NUMBER_OF_PROCESSORS
ONEDRIVE
OS
PATH
PATHEXT
PROCESSOR_ARCHITECTURE
PROCESSOR_IDENTIFIER
PROCESSOR_LEVEL
PROCESSOR_REVISION
PROGRAMDATA
PROGRAMFILES
PROGRAMFILES(X86)
PROGRAMW6432
PROMPT
PSMODULEPATH
PUBLIC
SESSIONNAME
SYSTEMDRIVE
SYSTEMROOT
TEMP
TMP
USERDOMAIN
USERDOMAIN_ROAMINGPROFILE
USERNAME
USERPROFILE
VBOX_MSI_INSTALL_PATH
WINDIR
PYTHONDONTWRITEBYTECODE
PIP_PYTHON_PATH
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH
:C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Python\Python37\;C:\Python\Python37\Scripts\;C:\Users\jerry\AppData\Local\Microsoft\WindowsApps;;C:\Program Files\Docker Toolbox;C:\Users\jerry\AppData\Local\Programs\Microsoft VS Code\bin;c:\users\jerry\bin;C:\Program Files\CMake\bin;c:\users\jerry\appdata\roaming\python\python37\scripts
Contents of
Pipfile
('C:\Users\jerry\d\udemy\projects-in-django\Pipfile'):Contents of
Pipfile.lock
('C:\Users\jerry\d\udemy\projects-in-django\Pipfile.lock'):C:\Users\jerry\d\udemy\projects-in-django>
The text was updated successfully, but these errors were encountered: