pipenv installs into .venv even though PIPENV_VENV_IN_PROJECT is not set #2763
Comments
|
Had to know this would cause problems somehow! |
|
I don’t even think there is a way to prevent this behavior. Sorry for the issue! |
|
@techalchemy That is unfortunate, considering my usage scenario. |
|
This behavior was explicitly added in #1492 |
|
This behavior has bitten me today. I mount my django app into a vagrant instance and set up the virtual environment into Being able to set the venv location explicitly via an env var would solve this problem for me. |
|
@foozmeat we've the same setup and problems at the moment... |
|
Would it be possible to use different folder names and then OS-depended checks? I.e. folder |
|
The code in #1492 looks like this:
So a workaround could be setting PIPENV_VENV_IN_PROJECT to false? (didn't test it myself) |
|
@abely That is the problem here, not having it set (or setting it to false) will go to the |
|
Well, it looks like where to put the environment is still biting after many years of debate. Came across this one after failing to the flag to work. So now it's totally broken:
Node/Javascript's npm and PHPs composer dependency management simply don't have this problem. Devs expect the damn runtime dependencies to be in their local directory. They .gitignore them for the repos. When they build for deployment the dependency lock file takes care of things and installs everything that is required, where it is expected to be. Down the build chain all the tools know exactly where to find things. Really, really simple How about having an additional flag for the base command, e.g. The world is not where it was 7 or 8 years ago. We are deploying to docker containers and lambda, not cold metal anymore. |
|
Upvoting @akzincsystems comment, a first-class command-line "put it here" directive like '--local' would be ideal. Note that with (at least) version 2020.11.15, the presence of Pipfile{,.lock} in a(ny) directory above the current (e.g. project) one supersedes the desired local creation one expects with PIPENV_VENV_IN_PROJECT set. Make sure |
|
Bump! Please address this issue. Even when I set it to a falsey value, it still tries to use Lines 243 to 248 in 9a3b3ce However, I was able get this working for me during development inside a docker container. Here are the commands I run: ln -sf "${PWD}/Pipfile" /tmp/Pipfile
ln -sf "${PWD}/Pipfile.lock" /tmp/Pipfile.lock
PIPENV_PIPFILE=/tmp/Pipfile pipenv installThe true champion is |
matteius
added
Type: Bug 🐛
|
@smac89 I don't quite understand the issue with the logical check in |
|
Maybe mine works fine because I have a |
|
@matteius the problem is that even if we set The correct solution should be to allow the user to explicitly opt in or out by setting PIPENV_VENV_IN_PROJECT to true or false, therefore only in the absence of Also yes I am using the lastest version |
|
@matteius If it helps, here is one use-case where this distinction between When we do python development, we test everything with docker-compose, and we usually mount our current working directory as a volume inside the container. Now sometimes, that current working directory may contain a Now if only there was a way to tell pipenv to ignore this |
matteius
added
PR: awaiting-review
Issue description
If a folder exists called .venv, pipenv will automatically install into it even though PIPENV_VENV_IN_PROJECT is not set.
Expected result
I expected it to install into the global virtual environment location (usually
/home/moo/.local/share/virtualenvs/)Actual result
It installed into
./.venv/Extra information
It is worth to note what I am trying to achieve.
I am running Windows and VS Code installed in Windows. But I am also running WSL. What I am trying to do is to use WSL (bash) as my terminal in VS Code. There are few things to consider here.
"python.pythonPath": "${workspaceFolder}/.venv",. For the VS Code extension to work, I need to executepipenv installin Windows Powershell or cmd (i.e. in Windows). This is since VS Code is installed in Windows.pipenv installin the integrated terminal (running WSL/bash) in the hopes that it will install to the global venv location. This way, I could properly use both VS Code with the python extension, and at the same time use the integrated terminal to run things there as well.Steps to replicate
$ pipenv --support
Pipenv version:
'2018.7.1'Pipenv location:
'/usr/local/lib/python3.5/dist-packages/pipenv'Python location:
'/usr/bin/python3'Other Python installations in
PATH:2.7:/usr/bin/python2.72.7:/usr/bin/python2.73.5:/usr/bin/python3.5m3.5:/usr/bin/python3.53.6:/usr/bin/python3.6m3.6:/usr/bin/python3.62.7.12:/usr/bin/python2.7.12:/usr/bin/python23.6.6:/usr/local/bin/python33.5.2:/usr/bin/python3PEP 508 Information:
System environment variables:
XDG_DATA_DIRSLESSCLOSEUSERLANGTERM_LOGNAMESHLVLOLDPWDLS_COLORSLESSOPENPIP_PYTHON_PATHSHELLNAMEPS1HOSTTYPEPWDPYTHONDONTWRITEBYTECODEPATHHOMEPipenv–specific environment variables:
Debug–specific environment variables:
PATH:/home/moo/bin:/home/moo/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Python36/Scripts:/mnt/c/Program Files/Python36:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Program Files/ctags58:/mnt/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit:/mnt/c/Program Files/Microsoft VS Code/bin:/mnt/c/Program Files/Git/cmd:/mnt/c/Windows/System32/OpenSSH:/mnt/c/Users/moo/AppData/Local/Microsoft/WindowsApps:/snap/binSHELL:/bin/bashLANG:en_US.UTF-8PWD:/home/moo/testContents of
Pipfile('/home/moo/test/Pipfile'):Contents of
Pipfile.lock('/home/moo/test/Pipfile.lock'):{ "_meta": { "hash": { "sha256": "50b8935d42537b1d392d8fe9a921302d58566b8b364c66af879714c0220b4483" }, "pipfile-spec": 6, "requires": { "python_version": "3.5" }, "sources": [ { "name": "pypi", "url": "https://pypi.org/simple", "verify_ssl": true } ] }, "default": { "certifi": { "hashes": [ "sha256:4c1d68a1408dd090d2f3a869aa94c3947cc1d967821d1ed303208c9f41f0f2f4", "sha256:b6e8b28b2b7e771a41ecdd12d4d43262ecab52adebbafa42c77d6b57fb6ad3a4" ], "version": "==2018.8.13" }, "chardet": { "hashes": [ "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae", "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691" ], "version": "==3.0.4" }, "idna": { "hashes": [ "sha256:156a6814fb5ac1fc6850fb002e0852d56c0c8d2531923a51032d1b70760e186e", "sha256:684a38a6f903c1d71d6d5fac066b58d7768af4de2b832e426ec79c30daa94a16" ], "version": "==2.7" }, "requests": { "hashes": [ "sha256:63b52e3c866428a224f97cab011de738c36aec0185aa91cfacd418b5d58911d1", "sha256:ec22d826a36ed72a7358ff3fe56cbd4ba69dd7a6718ffd450ff0e9df7a47ce6a" ], "index": "pypi", "version": "==2.19.1" }, "urllib3": { "hashes": [ "sha256:a68ac5e15e76e7e5dd2b8f94007233e01effe3e50e8daddf69acfd81cb686baf", "sha256:b5725a0bd4ba422ab0e66e89e030c806576753ea3ee08554382c14e685d117b5" ], "markers": "python_version >= '2.6' and python_version != '3.0.*' and python_version < '4' and python_version != '3.3.*' and python_version != '3.2.*' and python_version != '3.1.*'", "version": "==1.23" } }, "develop": {} }The text was updated successfully, but these errors were encountered: