# A deeper look into Pipenv and Poetry

It is 8 months passed since I posted the article comparing Pipenv with Poetry, which is the most popular article in my blog now. However, it was not a good review of the two tools, I have not even read the documentation of Poetry. In the end of last year I became a collaborator of Pipenv and util then have I realized there are so many trade-offs and, well, defects in Pipenv. In the area of software engineering, the successor always wins. The creator can't anticipate all corner cases in his prototype or original thoughts, especially for such a CLI tool that are run on millions of computers with totally different environment setup.

## Main problems with Pipenv

• Introduced more files of a new format, which is not perfect also. See how many miscellaneous files there are under the project root:
• The commands and options are always confusing and unclear, and the options are not fully tested to ensure the availability.
• Locking performance, there are many issues about dependency resolution. The rollment of passa may bring a big improvement, but the timeline is still not decided yet.
• Regression issues burned out users' patience. The test coverage is still very low, though testing against cross-platform and multi environment is a difficult and complicated mission.
• The maintainers are maintaining a large amount of projects backing Pipenv which need to be updated at a fairly high frequency. And it in turn brings high risk of regression. All PEEPs(Pipenv's enhancement proposals) need BDFL's approval while Kenneth Reitz is bothered by mental healthy and takes the back seat for a long time.

I myself are using Pipenv in daily work and help maintain Pipenv, too. So I wish a better future for Pipenv.

Poetry seems a better choice ya? I am also considering transfering to Poetry, but before that, I have to point out some downsides of it.

• Poetry doesn't work well with PyPA's current packaging system. It is very common that people clone a VCS repository and work on it. However, you can't pip install a Poetry project without extra steps to generate a setup.py from pyproject.toml.
• It is weird that Poetry puts python requires in dependency section. Python requires should be placed in global settings, although it shares the same version specifiers with normal dependencies.
• Neither Pipenv or Poetry supports to activate a virtualenv outside of project directory. I know it is inspired by NPM but in Python world people are likely to put some scripts in places other than the project directory. It is supported by virtualenvwrapper.
• Poetry only works under one workflow. For example, it doesn't support installing current dependencies into system Python, which is the typical workflow for developing in docker.

## What I expect in the future of Python packaging

I like the idea of "Every project is a package" and the introduction of pyproject.toml. It is introduced in PEP-508 but it is not finalized yet.

After PEP-508 is finalized, it is better that there is an official way to define dependencies in pyproject.toml, not in section like tool.poetry. It may look like:

Toml
[project]
name = "poetry"
version = "0.12.10"
description = "Python dependency management and packaging made easy."
authors = [
"Sébastien Eustace <sebastien@eustace.io>"
]
python = "~2.7 || ^3.4"
homepage = "https://poetry.eustace.io/"
repository = "https://github.com/sdispater/poetry"
documentation = "https://poetry.eustace.io/docs"

keywords = ["packaging", "dependency", "poetry"]

classifiers = [
"Topic :: Software Development :: Build Tools",
"Topic :: Software Development :: Libraries :: Python Modules"
]

# Requirements
[dependencies]
cleo = "^0.6.7"
requests = "^2.18"
cachy = "^0.2"
requests-toolbelt = "^0.8.0"
jsonschema = "^3.0a3"
pyrsistent = "^0.14.2"
pyparsing = "^2.2"
cachecontrol = { version = "^0.12.4", extras = ["filecache"] }
pkginfo = "^1.4"
html5lib = "^1.0"
shellingham = "^1.1"
tomlkit = "^0.5.1"

# The typing module is not in the stdlib in Python 2.7 and 3.4
typing = { version = "^3.6", python = "~2.7 || ~3.4" }

# Use pathlib2 for Python 2.7 and 3.4
pathlib2 = { version = "^2.3", python = "~2.7 || ~3.4" }
# Use virtualenv for Python 2.7 since venv does not exist
virtualenv = { version = "^16.0", python = "~2.7" }
# functools32 is needed for Python 2.7
functools32 = { version = "^3.2.3", python = "~2.7" }

[dev-dependencies]
pytest = "^3.4"
pytest-cov = "^2.5"
mkdocs = { version = "^1.0", python = "~2.7.9 || ^3.4" }
pymdown-extensions = "^6.0"
pygments = "^2.2"
pytest-mock = "^1.9"
pygments-github-lexers = "^0.0.5"
black = { version = "^18.3-alpha.0", python = "^3.6" }
pre-commit = "^1.10"
tox = "^3.0"
pytest-sugar = "^0.9.2"

[scripts]
poetry = "poetry.console:main"



I hope pyproject.toml will eventually replace setup.py, and in the transition period, Pip, or whatever name, should be able to read both files. The "Pip" should be a combination of Pipenv and Poetry and be the ultimate solution for Python packaging.

## Update

Another drawbacks I found recently: Pipenv, or more precisely, virtualenv, doens't use the built-in venv module to create a VE, which may bring troubles:

• When the Python interpreter is updated, the VE will become stale.
• Some packages such as matplotlib requires framework build on macOS. Virtualenv creates non-framework build even if the original one is framework-build

I forked the virtualenv with a patch to address these problems. Replace the PyPI virtualenv via:

Bash
\$ pip install -I https://github.com/frostming/virtualenv-venv/releases/download/16.2.0-fork/virtualenv-16.2.0_fork-py2.py3-none-any.whl


Everything works well now.

Last edited

Ben

"Neither Pipenv or Poetry supports to activate a virtualenv outside of project directory."

I'm not quite following this. Pipenv, by default, stores virtualenvs under ~/.local/share/virtualenvs so you must mean that it doesn't allow activation of a virtualenv in an arbitrary location.

I think, though, that you can simply activate the virtualenv and pipenv will detect that it's already running in a virtualenv. I could definitely apprecaite that that's a bit janky, though.

"The creator can't anticipate all corner cases in his prototype or original thoughts, especially for such a CLI tool that are run on millions of computers with totally different environment setup."

Yup. You might think you've seen some weird cases because you've worked on software for a while, but package managers and build tools run into everything imaginable and then some.

that you can simply activate the virtualenv and pipenv will detect that it's already running in a virtualenv. I could definitely apprecaite that that's a bit janky, though.

Yes that can work, I just found that virtualenvwrapper works pretty well for this case, but it would be better if it's built in with Pipenv/Poetry.

zhangtao

gamesbook

"For example, it doesn't support installing current dependencies into system Python, which is the typical workflow for developing in docker."
I have actually seen many arguments that you should, in fact, be using a virtual enviroment in the Docker as well and NOT messing with installs into the global Python library.

Dmitry Figol
you can't pip install a Poetry project without

You can since pip supports PEP-517/518.

It is weird that Poetry puts python requires in dependency section

why?

For example, it doesn't support installing current dependencies into system Python

It does. poetry config settings.virtualenvs.create false

1. Yes it needs to be updated.
2. Python requires is definitely different from install or dev requires, the former specifies which Python version is supported while the latter is the PyPI packages that are depended on.
3. First time to know that but it is not as convenient as directly passing an option to install command.