Environment Tools: Pipenv

In the last few articles we have talked about pyenv, pipx, and pip-tools. Now lets move on to the next tool - Pipenv.

Pipenv: Python Dev Workflow for Humans — pipenv 2023.6.19.dev0 documentation

Like pip-tools, pipenv also mainly focuses on resolving dependencies and creating the lock file. Unlike pip-tools, which requires a pre-existing virtual environment, pipenv also creates and manages the virtual environment.

Installation

Use pipx to install pipenv

> pipx install pipfile

This will download and install pipenv.

Next, we create an empty directory where we want to put our project files (or to an existing project that already has files), and run the command pipenv install.

First, pipenv will check if there is a pipenv managed virtualenv associated with this project directory. Since this is the first time we are running the command, there won't be any, so pipenv will go ahead and create a new virtual enviroment. Usually these virtual environments are located in .virtualenvs directory within the user's home directory.

Declaring Dependencies

Upon installation, pipenv will create two files: Pipfile and Pipfile.lock. The first one, Pipfile is where you configure the dependencies your project requires. This is where pipenv uses a slightly non-standard way of doing it as Pipenv does not support defining dependencies in pyproject.toml, rather it uses it's own file Pipfile to do the same.

The initial Pipfile will look like this

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]

[dev-packages]

[requires]
python_version = "3.11"

We can now go into the [packages] or [dev-packages] sections and add the dependencies for our project. After that, run pip install to download and install those packages.

Actually, you don't even need to edit the file. Running pipenv install <packagename> will install the package and also add that package to your Pipfile all at once.

In a similar vein, pipenv uninstall <packagename> will uninstall a package and pipenv sync will sync the virtual environment with the dependencies specified in the lock file.

The Pipfile.lock contains the exact dependencies that get installed. The next time anyone does a pipenv sync, they will get the exact same dependencies installed in the environment. By default, Pipenv also stores hashes in the lock file, so the builds are secure by default.

Running Code

Since pipenv creates and manages the virtualenv, we don't manually have to activate or deactivate the virtualenv.

Instead, we do pipenv run <command> and pipenv will know which is the virtualenv created for that project and will run the given command within the activated context of that virtualenv. When we return to the command prompt, we are back outside the virtualenv.

Sometimes we want to run many commands within the context of the virtualenv. Using the pipenv shell command will create a shell with the virtualenv activated. Anything we do in that shell will be in the context of the virtualenv. Exiting the shell takes us out of the virtual environment and back into the regular prompt.

Managing Deployments

One potential issue is that Pipenv does not use the standardised pyproject.toml or requirements.txt formats. The question then is, how to manage dependencies in a production deploymment where we only have regular pip available? Do we need to install Pipenv so that we can install the dependencies from Pipfile.lock?

Fortunately, there is a solution. The pipenv requirements command will take the Pipfile.lock file and generate an equivalent requirements.txt. This file can be used to install all the dependencies on a system that only has vanilla pip available.

Another nice feature is the pipenv check command which checks the PyUp database to check if there are any known security issues in any of your dependencies.

Summary

Pipenv goes a step ahead of pip-tools by not only managing your dependencies, but also managing the virtual environment. Pipenv gives reproducible and secure builds by default, and the feature to validate dependencies against a database of known security issues is a welcome one. It would be nice if Pipenv supported the pyproject.toml format instead of using it's own Pipfile. Still if you are working on an older project that doesn't use pyproject.toml then that might just be a feature. In that sense, Pipenv can easily integrate into various project setups with minimal effort.