From the docs:
It automatically creates and manages a virtualenv for your projects, as well as adds/removes packages from your Pipfile as you install/uninstall packages. It also generates the ever-important Pipfile.lock, which is used to produce deterministic builds.
There’s a lot of information on the pipenv web site. Unfortunately, as I remarked to a friend once, it’s as if someone wrote all the thoughts they had about pipenv on note cards, threw them up in the air, and added them to the site in the order they fell. In other words, it’s difficult to navigate or find the information you want.
Here’s an attempt at a useful table of contents.
Installation and configuration
Converting an existing project
General day-to-day usage
Most of these “options” are basically additional commands, except there’s no documentation other than the one-liners included here, so I haven’t bothered giving links for these:
--where- output project home information
--venv- output virtualenv information
--py- output Python interpreter information
--envs- Output Environment Variable options.
--rm- remove the virtualenv
--bare- minimal output
--completion- output completion (to be executed by the shell)
--man- display manpage
--support- Output diagnostic information for use in GitHub issues.
--no-site-packages- Enable or disable site-packages for the virtualenv.
--python <python>- Specify which version of Python virtualenv should use.
--two- Use Python 3/2 when creating virtualenv.
--clear- Clears caches (pipenv, pip, and pip-tools).
--verbose- verbose mode
--version- show the version and exit
You need to install pipenv OUTSIDE your project’s virtual environment AND if at all possible, not as part of your system packages.
I like to use pipx.
There’s no command to create a virtualenv. Pipenv just creates one as soon as one is needed.
EXCEPT, if pipenv detects that it is running inside a virtualenv, it uses that one. So there’s a kind of escape hatch: create a virtualenv anyway/anywhere you want, install pipenv into it, then activate it, and pipenv will use it. (Set PIPENV_IGNORE_VIRTUALENVS to disable that behavior.)
Pipenv generates a name for each virtualenv based on the project directory path and a hash. So if you move your project, pipenv will no longer find that virtualenv and will have to create a new one.
PIPENV_VENV_IN_PROJECT=1 is set, pipenv creates your virtualenv under your project directory,
in a directory name
WORKON_HOME is set, pipenv creates virtualenvs under that directory.
WORKON_HOME can be set to a relative directory. For example, if I set it to
generates a virtualenv name as usual and creates it under the parent directory, beside my
If neither PIPENV_VENV_IN_PROJECT nor was set,
it created them for me under
Since I have pipenv installed under
~/.local/bin, I wonder if that path
is connected to where pipenv is installed, or is always that path?
is there a way to tell pipenv to use some other algorithm to generate the path to the virtualenv?
You can delete a virtualenv with
There’s no command (that I’ve found) to prune old ones. That’s on you.
Converting from a requirements file¶
Just run “pipenv install [-r requirementsfile]” and it’ll see that there’s no Pipfile but a requirements file, and will generate a new Pipfile and .lock file for you. Then edit the Pipfile to clean it up.
Starting a new project¶
Just change to the project directory and start using
pipenv install <packagespec> [<packagespec>...]
to install packages. Pipenv will create a Pipfile and Pipfile.lock the first time, and update it as you
install more packages.
Creating a requirements file¶
pipenv lock --requirements >non-dev-requirements.txt pipenv lock --requirements --dev >only-dev-requirements.txt
Keeping dev-only packages out of production¶
Add dev-only packages using
pipenv install --dev <packages>
For development, install using
pipenv install --dev
In production, leave off the