Pipenv: promises a lot, delivers very little

Application dependencies

Here is an example use case for Pipenv:
I’m working on a website based on Django. I create ~/git/website and run
pipenv install Django in that directory. Pipenv:

• automatically creates a virtualenv somewhere in my home directory
• writes a Pipfile, which lists Django as my dependency
• installs Django using pip
• proceeds to write Pipfile.lock, which stores the exact version and source file hash [2] of each package installed (including pytz, Django’s dependency).

The last part of the process was the most time consuming. At one point, while
locking the dependency versions, Pipenv hangs for 46 seconds. This is one of
Pipenv’s notable issues: it’s slow. Of course, this isn’t the only one,
but it defintely doesn’t help. Losing 46 seconds isn’t much, but when we get to
the longer waits in the timing test section later, we’ll see something that
could easily discourage users from using a package.

Running scripts (badly)

But let’s continue with our workflow. pipenv run django-admin startproject
foobanizer is what I must use now, which is rather unwieldy to type, and
requires running pipenv even for the smallest things. (The manage.py script
has /usr/bin/env python in its shebang.) I can run pipenv shell to get
a new shell which runs the activate script by default, giving you the worst
of both worlds when it comes to virtualenv activation: the unwieldiness of a
new shell, and the activate script, which the proponents of the shell spawning
dislike.

Using pipenv shell means spawning a new subshell, executing the shell
startup scripts (eg. .bashrc), and requiring you to exit with exit or
^D. If you type deactivate, you are working with an extra shell, but now
outside of the virtualenv. Or you can use the --fancy mode that manipulates
$PATH before launching the subshell, but it requires a specific shell
configuration, in which $PATH is not overridden in non-login shells — and
also often changing the config of your terminal emulator to run a login shell,
as many of the Linux terminals don’t do it.

Now, why does all this happen? Because a command cannot manipulate the
environment of the shell it spawns. This means that Pipenv must pretend what it
does is a reasonable thing instead of a workaround. This can be solved with
manual activation using source $(pipenv --venv)/bin/activate (can be made
into a neat alias), or shell wrappers (similar to what virtualenvwrapper does).

Finishing it all up

Anyway, I want a blog on my site. I want to write them in Markdown syntax, so I
run pipenv install Markdown, and a few long seconds later, it’s added to
both Pipfiles. Another thing I can do is pipenv install --dev ipython and
get a handy shell for tinkering, but it will be marked as a development
dependency — so, not installed in production. That last part is an important
advantage of using Pipenv.

When I’m done working on my website, I commit both Pipfiles to my git
repository, and push it to the remote server. Then I can clone it to, say,
/srv/website. Now I can just pipenv install to get all the production
packages installed (but not the development ones — Django, pytz, Markdown will
be installed, but IPython and all its million dependencies won’t). There’s just
one caveat: by default, the virtualenv will still be created in the current
user’s home directory. This is a problem in this case, since it needs to be
accessible by nginx and uWSGI, which do not have access to my (or root’s)
home directory, and don’t have a home directory of their own. This can be
solved with export PIPENV_VENV_IN_PROJECT=1. But note that I will now need
to export this environment variable every time I work with the app in /srv
via Pipenv. The tool supports loading .env files, but only when
running pipenv shell and pipenv run. You can’t use it to configure
Pipenv. And to run my app with nginx/uWSGI, I will need to know the exact virtualenv
path anyway, since I can’t use pipenv run as part of uWSGI configuration.

Setup.py, source distributions, and wheels

Pipenv only concerns itself with managing dependencies. It isn’t a packaging
tool. If you want your thing up on PyPI, Pipenv won’t help you with anything.
You still need to write a setup.py with install_requires, because the
Pipfile format only specifies the dependencies and runtime requirements (Python
version), there is no place in it for the package name, and Pipenv does not
mandate/expect you to install your project. It can come in handy to manage the
development environment (as a requirements.txt replacement, or something
used to write said file), but if your project has a setup.py, you still
need to manually manage install_requires. Pipenv can’t create wheels on its
own either. And pip freeze is going to be a lot faster than Pipenv ever
will be.

Working outside of the project root

Another issue with Pipenv is the use of the working directory to select
the virtual environment. [3] Let’s say I’m a library author. A user of my foobar
library has just reported a bug and attached a repro.py file that lets me
reproduce the issue. I download that file to ~/Downloads on my filesystem.
With plain old virtualenv, I can easily confirm the reproduction in a spare
shell with:

$ ~/virtualenvs/foobar/bin/python ~/Downloads/repro.py

And then I can launch my fancy IDE to fix the bug. I don’t have to cd into
the project. But with Pipenv, I can’t really do that. If I put the virtualenv
in .venv with the command line option, I can type
~/git/foobar/.venv/bin/python ~/Downloads/repro.py. If I use the
centralized directory + hashes thing, Tab completion becomes mandatory, if I
haven’t memorized the hash.

$ cd ~/git/foobar
$ pipenv run python ~/Downloads/repro.py

What if I had two .py files, or repro.py otherwise depended on being in
the current working directory?

$ cd ~/git/foobar
$ pipenv shell
(foobar-Mwd1l2m9)$ cd ~/Downloads
(foobar-Mwd1l2m9)$ python repro.py
(foobar-Mwd1l2m9)$ exit  # (not deactivate!)

This is becoming ugly fairly quickly. Also, with virtualenvwrapper, I can
do this:

$ cd ~/Downloads
$ workon foobar
(foobar)$ python repro.py
(foobar)$ deactivate

And let’s not forget that Pipenv doesn’t help me to write a setup.py,
distribute code, or manage releases. It just manages dependencies. And it
does it pretty badly.

Nikola

I’m a co-maintainer of a static site generator, Nikola. As part of this, I have the following places where
I need to run Nikola:

• ~/git/nikola
• ~/git/nikola-site
• ~/git/nikola-plugins
• ~/git/nikola-themes
• ~/website (this blog)
• /Volumes/RAMDisk/n (demo site, used for testing and created when needed, on a RAM disk)

That list is long. End users of Nikola probably don’t have a list that long,
but they might just have more than one Nikola site. For me, and for the
aforementioned users, Pipenv does not work. To use Pipenv, all those
repositories would need to live in one directory. I would also need to have a
separate Pipenv environment for nikola-users, because that needs Django.
Moreover, the Pipfile would have to be symlinked from ~/git/nikola if we
were to make use of those in the project. So, I would have a ~/nikola
directory just to make Pipenv happy, do testing/bug reproduction on a SSD (and
wear it out faster), and so on… Well, I could also use the virtualenv directly.
But in that case, Pipenv loses its usefulness, and makes my workflow more
complicated. I can’t use virtualenvwrapper, because I would need to hack a
fuzzy matching system onto it, or memorize the random string appended to my
virtualenv name. All because Pipenv relies on the current directory too much.

Nikola end users who want to use Pipenv will also have a specific directory
structure forced on them. What if the site serves as docs for a project, and
lives inside another project’s repo? Two virtualenvs, 100 megabytes wasted.
Or worse, Nikola ends up in the other project’s Pipfile, which is technically
good for our download stats, but not really good for the other project’s
contributors.

Hatch

Hatch tries to take care of everything in the packaging process. This is
mostly an asset, as it helps replace other tools. However, it can also be
argued that it adds a single point of failure. Hatch works on already standard
files, such as requirements.txt and setup.py, so it can be replaced with
something else quite easily. It doesn’t use as much magic as Pipenv and is more
configurable. Some choices made by
Hatch are questionable (such as manually parsing pkg/__init__.py for a
version number, installing test suites to site-packages (a rather common oversight), or its shell feature which is as ugly as Pipenv’s), and it does
not do anything to manage dependencies. It doesn’t necessarily work for the
Django use case I mentioned earlier, or for end-users of software.

Poetry

Poetry is somewhere in between. Its main aim is close to Pipenv, but it
also makes it possible to distribute things to PyPI. It tries really hard to
hide that it uses Pip behind the scenes. Its README comes with an extensive
“What about Pipenv?”
section, which I recommend reading — it has a few more examples of bad Pipenv
features. Poetry claims to use the standardized (PEP 518) pyproject.toml
file to replace the usual lot of files. Unfortunately, the only thing that is
standardized is the file name and syntax. Poetry uses custom [tool.poetry]
sections, which means that one needs Poetry to fully use the packages created
with it, leading to vendor lock-in. (The aforementioned Hatch tool also
produces a pyproject.tmpl, which contains a metadata section…) There is
a build feature to produce a sdist with setup.py and friends.

In a simple poetry add Nikola test, it took 24.4s/15.1s/15.3s to resolve
dependencies (according to Poetry’s own count, Remote environment, caches
removed), complete with reassuring output and no quiet lockups. Not as good as
pip, but it’s more reasonable than Pipenv. Also, the codebase and its layout
are rather convoluted. Poetry produces packages instead of just managing
dependencies, so it’s generally more useful than Pipenv.

Pip is here to stay!

But in all the talk about new tools, we’re forgetting about the old ones, and
they do their job well — so well in fact, that the new tools still need them
under the covers.

Pip is fast. It does its job well enough. It lacks support for splitting
packages between production and development (as Pipenv and Poetry do). This
means that pip freeze and pip install are instant, at the cost of (a)
needing two separate environments, or (b) installing development dependencies
in production (which should only be a waste of HDD space and nothing more in
a well-architected system).

The virtualenv management features can be provided by virtualenvwrapper. That
tool’s main advantage is the shell script implementation, which means that
workon foo activates the foo virtualenv without spawning a new
subshell (an issue with Pipenv, Hatch, and Poetry, that I already covered when
describing Pipenv’s operation in the Running scripts (badly) chapter.) An
argument often raised by Pipenv proponents is that one does not need to concern
itself with creating the virtualenv, and doesn’t need to care where it is.
Unfortuntately, many tools require this knowledge from their user, or force a
specific location, or require it to be different to the home directory.

And for a reasonable project template with release automation — well, I have my
own entry in that category, called (rather unoriginally) the Python Project
Template (PyPT).

Yes, setup.py files are not ideal, since they use .py code and a function
execution, making access to meta information hard (./setup.py egg_info
creates tool-accessible text files). Their main advantage is that they are the
only format that is widely supported — pip is the de-facto default
Python package manager (which is pre-installed on Windows and Mac), and other
tools would require installation/bootstrapping first.