Pipenv: Remember where the virtual environment was created

[jacebrowning]

This is a feature request inspired by Bundler.

I have PIPENV_VENV_IN_PROJECT=true set in my build scripts, but occasionally I will run a pipenv command manually which triggers the creation of a whole new virtual environment despite one existing locally in .venv.

It would be nice if pipenv could locate the virtual environment for a project a bit more intelligently.

---

Bundler solves this problem by creating a local, hidden configuration file. After installing gems to a specific location:

```
$ bundle install --path=vendor/bundler

Bundler writes to `.bundler/config`:

---

BUNDLE_PATH: "vendor/bundler"
BUNDLE_DISABLE_SHARED_GEMS: "true"
```

So that future calls to $ bundle install with use vendor/bundler without needed to specify a custom path.

---

pipenv could do something similar with a configuration file or simply rely on the fact that .venv is a convention for virtual environments and use .venv if it exists.

[nateprewitt]

I'm not averse to the idea of a config file, I think I could help solve some other issues in pipenv too.

occasionally I will run a pipenv command manually which triggers the creation of a whole new virtual environment despite one existing locally in .venv.

This, however, I'm not sure I understand. It seems much more like a bug in how we're handling commands which means we probably shouldn't immediately throw a config patch on it. How often is occasionally? Do you have a specific set of commands that trigger this? Does it create the new environment with pew or overwrite the existing .venv? Do you have PIPENV_VENV_IN_PROJECT set in your .profile or are you setting it for each shell session?

[jacebrowning]

Do you have PIPENV_VENV_IN_PROJECT set in your .profile or are you setting it for each shell session?

I am setting variables in a Makefile via export PIPENV_VENV_IN_PROJECT=true so that commands like make install, make test, etc. can call each other, rely on build system caching, and access the virtual environment in a known location.

Occasionally, I want to jump into a Python shell ($ pipenv run python), but this ignores the existing .venv and calls pew to create a virtual environment somewhere else on my system.

[nateprewitt]

Yep, I can see how that would be problematic. So the more I'm thinking about it, the more I'm definitely in favor of a project based config file. It will allow people to, for now, set project specific environment variables, and later make configurability much easier.

I don't know what @kennethreitz's thoughts are on this, but I believe I'm +1.

Here's an initial mockup (967c975) of what I'm thinking, if there's interest.

.pipenv file in project directory (could be .pipenv/config), TOML format, currently only supports the [environment] table which will have keys in the format:

[environment]
PIPENV_VENV_IN_PROJECT = "1"
PIPENV_COLORBLIND = "1"

The file will be loaded when we validate the environment and initialize those shell env variables for the running that pipenv command.

[jacebrowning]

👍 For using the same format as the Pipfile.

I'm thinking this file should be generated automatically when the virtual environment is created to capture the current statue of PIPENV_* environment variables. Perhaps the configuration file is only created if one of the PIPENV_* environment variables is set.

Are you thinking this file would be committed to the repository? I could go either way.

[nateprewitt]

Commiting the file to the repo can be entirely user choice, it won't have a real effect for fresh environment spaces.

I'm slightly leery of capturing the environment state every time the user creates a new environment. I'm willing to bet there are some who are using pipenv --three-style commands to simply clear out the virtualenv. While automation is nice, this isn't a significant task to add a few lines to the file by hand, and the user won't have to worry about shooting themselves in the foot with an accidental rebuild.

That said, I'm not entirely ruling out automation, but I think we should build this incrementally. That will allow us to determine if automation really is needed, rather than building in functionality that could be problematic and having to remove it. That's always a much bigger hassle for everyone.

[kennethreitz42]

we could add this configuration to Pipfile, if at all.

[nateprewitt]

So I think we could integrate this into the Pipfile but that means a.) expanding the spec of Pipfile and b.) bundling deployment specific details into the dependency format. I'd think it would be best to decouple things like PIPENV_COLORBLIND from the project. That's a user specific decision that isn't necessarily wanted on all platforms. It also make expanding the config options more difficult because it would store things like install_path that are specific to a single machine in the dependency format.

I know adding a .pipenv or .pipenv/config file is added overhead, but it seems like the saner approach in comparison to trying to make Pipfile do everything.

[kennethreitz42]

I don't want us to have a config file — something i'll need to think about.

[uda]

I just upgraded from 3.4.2 to 3.5.6, and all of the venvs created by pipenv are now unused and new ones are being created, this could have been avoided.
One suggestion is to use the .venv file I am using for oh-my-zsh's virtualenvwrapper plugin, simple and multi-purpose.
I am not saying this or that solution should be used, just that A solution should be used, this is a real issue.

[nateprewitt]

Hey @uda, we do support a local .venv directory if you enable the environment variable PIPENV_VENV_IN_PROJECT. The directory name change you've noted was a one time change in 3.5.0 to prevent project collisions that were accidentally deleting existing environments.

While I sympathize with the pain of having to clean up the existing directories, it's a one time expense that helps solve a significant issue with our previous venv naming design. Overall, it has been a net gain for everyone.