Pipenv: PIPENV_VENV_IN_PROJECT=true should be default behavior

[olegantonyan]

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?

[ed-alertedh]

See #178

[olegantonyan]

That's weird

As a note, now that the original "put virtualenv in project dir" default behavior has been changed (sadly), the Pipenv README should be changed. It shows a virtualenv getting created in the project dir.

But why? I don't understand why would anyone change good design to bad

[uranusjr]

@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 PIPENV_VENV_IN_PROJECT on my machine. I just don’t think either is objectively superior, at least not much.)

[RobertoMaurizzi]

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=\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.
Now, if I only understood why 9.0.x is eating my #egg= URL fragments I'd be an happy camper... ;-)

[olegantonyan]

@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).

[techalchemy]

@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

[QUDUSKUNLE]

@olegantonyan How did you solve this problem? I try to set PIPENV_VENV_IN_PROJECT=true, it did not solve the problem as well. Any clue?

[olegantonyan]

@QUDUSKUNLE yes, PIPENV_VENV_IN_PROJECT=true works for me

[techalchemy]

The environment variable works fine for most people, if you are having a problem with it please file a separate issue.

[abhi-infrrd]

Using PIPENV_VENV_IN_PROJECT=true makes it more easier to activate virtual environment in a dockerfile which otherwise would depend on activating an environment based on some hash value pertaining the project.

[techalchemy]

pipenv shell is the UI for activation

[uranusjr]

I believe whole-heartedly it makes things more easier for your workflow if PIPENV_VENV_IN_PROJECT is the default. It does for me as well. There is, however, everyone else, who feels it awkward to have .venv in their projects, and demand PIPENV_VENV_IN_PROJECT to be off by default. There is no way we can satisfy both camps, and we still have to pick a default. Please be considerate of our position. We can’t change the behaviour now.

[ncoghlan]

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 .venv in the project directory, it will get mounted into each container instance along with the rest of the source code).