-
-
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_VENV_IN_PROJECT=true should be default behavior #1382
Comments
See #178 |
That's weird
But why? I don't understand why would anyone change good design to bad |
@olegantonyan I don’t think either design is bad (or good). There is wild-spread usage of tools using a centralised virualenv storage, such as virtualenvwrapper, Anaconda’s virtualenv support, and pyenv-virtualenv. I’d guess none of their users think it is a bad idea. It is subjective. (Disclaimer: I do prefer the virtualenv-beside-project approach, and set |
I guess the main issue with a lot of new users is that default behaviour is unexpected and meddling: most, like me, come from using 'hand-rolled' environments using pip, maybe they're mostly working on one project at a time so you don't already use virtuaalenvvrapper (and you didn't set WORKON_HOME=<decent path where my server is expecting the venvs>) and you don't immediately find what to do because environment vars are explained in the advanced documentation If you do read it, you can customize pipenv how you like it most and you gain a lot. The only issue I can see is that if you were happy with virtualenvwrapper (i.e having a managed set of "standard" venvs you pick from) then that's gone, but to be honest I think that's an anti-pattern, I want what pipenv is doing: per project venv with dependency management and file validation/locking. |
@uranusjr yeah, good/bad is probably a bad measure here, and those developers of anaconda and other tools are smarter than me, but the whole my experience is telling me that this isn't right. I'm ok with reasoning "this is the way I/we/someone like it, don't use it if you don't. period", but there's probably better explanation besides historical reasons (virtualenvwrapper, anaconda, etc). |
@RobertoMaurizzi there was a series of breakages in commit history in the last release which caused that issue. It is fixed again in #1372. @olegantonyan following convention and user expectation seems like a pretty solid reason for operating a certain way IMO. The fact that this is easily configurable for anyone who disagrees makes the point kind of irrelevant though I’m going to close this for now since, as @uranusjr mentioned, it was a design decision and I suspect we would need a compelling reason to change it |
@olegantonyan How did you solve this problem? I try to set |
@QUDUSKUNLE yes, |
The environment variable works fine for most people, if you are having a problem with it please file a separate issue. |
Using |
|
I believe whole-heartedly it makes things more easier for your workflow if |
Just noting one of the Docker-related trade-offs here for possible future doc updates: if you're running multiple different docker images (e.g. 32-bit vs 64-bit, different base distro versions), and mounting the development directory into the images, then the default behaviour keeps those images from conflicting with each other, and with the native builds on the host dev machine. At the same time, the downside of the default behaviour is that if you're not pre-creating the environment as part of the Docker image build process, then it will need to be recreated each time the containers restart (whereas with a |
Is there a reason why pipenv is poluting
~
with virtualenvs by default? To me it doesn't make any sense. If the specific virtualenv is associated with specific project than why store it somewhere deep inside your~
and not in the project's folder?The text was updated successfully, but these errors were encountered: