Python packaging war: Pipenv vs. Poetry

This is my second post about Python packaging. In the last post, I regarded npm as my ideal packaging management tool because I had limited experience about other tools in other languages. Honestly saying, npm is never perfect with many drawbacks in its own, but it also has many things we can learn from.

Pipenv, brought to the community again by Kenneth Reitz on PyCon 2018, which is also mentioned in the last post, is more than 1 year old since it was born. In the past months I have becomed a contributor of the project, during which time I gained more understanding of its philosophy and design purpose. As explained here, Pipenv is designed for application deps management, rather than libraries. You still have to maintain a setup.py file besides Pipfile to serve as a library configuration file. From my daily experience of using this amazing project, it handles all the messing stuff of virtualenvs and installation, which saves lots of lines in README.md, but it's far from perfect regarding the issue number in its issue tracker.

Then I encountered a much younger project -- Poetry, which is only 3 months old with less than 600 starts on GitHub repo(compare to 11000+ stars of Pipenv). Poetry uses standardized pyproject.toml instead of customized Pipfile as the project deps configuration file. It's more like a packaging.json as in Javascript's packaging world in following ways:

1. It can serve for both applications and libraries, depending on whether you do upload or not.
2. Packages are prefered to be installed with non-wildcard version, with support of multiple version specifiers

Poetry does a lot of work on deps resolution and packaging, so that pyproject.toml can replace setup.py, it is monolithic. While Pipenv is more like a wrapper built on top of pip and virtualenv(or pew). Kenneth Reitz is very good at adopting amazing tools and merge them together to be a project really powerful and easy to use(same as requests-html), but SDispater, with his Poetry, in my honest opinion, is making Python packaging much different.

I am not putting down any one and raising the other, but the current status is that Pipenv is more exposed to the community with KR's fame and great talks, and it's also adopted by PyPA. But PyPA is never an authority though the word is in its name, and standard may change. For the long time of view, let the large community choose the winner, but before it's finalized, there must be a war between these two tools.