pipenv: Default virtualenv location and pipenv shell problems

no plans for making it configurable.

it sounds like your shell is not properly configured.

released!

added PIPENV_VENV_IN_PROJECT mode for classic operation. Not released yet.

Please add an option in the Pipfile to enable PIPENV_VENV_IN_PROJECT behavior. Requiring an environment variable defeats the purpose of the Pipfile/pipenv.

I think at the moment I’m only proposing a change of:

$ pipenv install
Creating a virtualenv for this project...
...
No package provided, installing all dependencies.
Virtualenv location: /Users/kennethreitz/repos/kr/pip2/test/.venv

…to show the virtualenv location at /Users/kennethreitz/.local/share/virtualenvs etc.

It would have helped me if it said, instead of:

Automatically creates a virtualenv in a standard location.

…perhaps in a central location, but configurable.. But again, it’s likely only me that is bugged by the change in policy. I spent quite a while looking for a discussion about the rationale, but couldn’t find it. Still, it’s a fast-moving project designed to have opinions, and nobody owes me squat. 😃

From a system administration perspective, it makes more sense to default to store the venv in the project, because if we simply remove the project, there are no artifacts on the system. Also, it does not appear to be instinctive to know which venv are artifacts (to save space).

From a developer perspective, it makes more sense to default to store the venv in the project, because it means we can simply share the projects folder with someone else, no installation step required. Which was one of the purposes of the initial venv.

From https://virtualenv.pypa.io/en/latest/:

In all these cases, virtualenv can help you. It creates an environment that has its own installation directories [...]

About the softwares that need a central location for the venv (I must warn that I don’t know all the reasons those softwares need a central location). From my point of view, those softwares could:

• ask the user to set the VARIABLE to use a central location themselves (in bashrc or equivalent)
• add the VARIABLE in the pipfile of projects they manage (I don’t know if it is supported)
• support the fact that by default, venv are in the project

To conclude, I don’t see any advantages (except for third party utilities) to have a central location for venv (please correct me on this). I understand that it would involve some work for third party utilities, but I think this is the kind of change that should be made on a major update.

I just want to point out this makes installing packages from Pipfile.lock easier in docker/containers without shipping pipenv in the final build, allowing us to trivially copy only .venv and relevant source code to the final image without having to determine the package venv directory by hash/location etc.

Hrm, this doesn’t work as expected:

$ pipenv --where

Pipfile found at /Users/myusername/Desktop/dev/projectname/Pipfile. Considering this to be the project home.

What I would expect is: /Users/myusername/.local/share/virtualenvs/projectname

Then I can programmatically use pipenv --where with other shell commands to do things like manually linking system opencv.

Yep, I gave that env var a try and it worked. However, it’s no longer the default behavior, so I thought I’d note that the home page is out of date in that regard.

I agree it is a minor detail, and it’s likely only me that notices it, because I’m disappointed at the change of default. But that’s an emacs vs. vi argument that doesn’t need to be re-opened.

—Paul

On Feb 24, 2017, at 9:42 AM, Nate Prewitt notifications@github.com wrote:

Hey @pauleveritt https://github.com/pauleveritt, just to be clear, the virtualenv in project dir functionality is still available but now requires an environment variable PIPENV_VENV_IN_PROJECT to activate. Placing this in your bash profile will enable this functionality as the default.

I can only find one reference to a venv in the local directory and I don’t know if I’d consider that terribly misleading. We could change the path displayed but I’m not sure if that provides any significant improvement in understanding. Each project will tell you where it’s installed at initialization and is easy to find with pipenv --where.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kennethreitz/pipenv/issues/178#issuecomment-282307779, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbx5jdMB_3oEnMZ9Zw0iSWqeAgtD5DVks5rfuxngaJpZM4LzhjH.

@madhavajay Maybe you’re looking for pipenv --venv instead?

Hey @pauleveritt, just to be clear, the virtualenv in project dir functionality is still available but now requires an environment variable PIPENV_VENV_IN_PROJECT to activate. Placing this in your bash profile will enable this functionality as the default.

I can only find one reference to a venv in the local directory and I don’t know if I’d consider that terribly misleading. We could change the path displayed but I’m not sure if that provides any significant improvement in understanding. Each project will tell you where it’s installed at initialization and is easy to find with pipenv --where.

Thank you very much! I figured out that in new version you did use pew to manage virtualenv and that is great, but pew is not supporting pyenv, which i use, and this is what causes the problem. I decided to refuse of pyenv in favour of pew, but this issue may target all of pyenv users.

this will also restore your shell functionality, although i would recommend fixing your shell configuration.