Remember where the virtual environment was created

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]

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.

[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.