Pipenv投入使用后的回顾

2018 年 5 月 23 日 Python程序员

如果你没有在reddit上订阅/r/Python频道，那么你可能不知道有关Python Packaging Authority、pipenv和poetry各自现今状况的话题讨论。pipenv和poetry的作者及PyPA的代表的参与使得这场讨论变得更为有趣。如果你不介意在诸多无用的情绪化表达中寻找有趣的观点，那就请便吧。

目前python的打包处理很糟糕，应该没有人否认这一点。既然存在这个问题，那么就有很多试图解决这种混乱状况的尝试。Pipenv是第一个迈出这一步的，同时它也获得了很大的进步，但它并不适合所有人。同时它也不适合所有项目——比如库。

我使用Pipenv已经有一段时间了，我还试着将它引入到我们团队的代码库中。自2017年11月左右开始，我们一直在使用Pipenv，2017年5月，我个人在GitHub上创建了我的第一个项目，以下是我的经验：

多环境问题

在编号＃368的问题中我首先讨论了多环境（例如测试了2.7和3.6）。我解决了我的项目中使用问题，但是＃1050仍然在讨论这个问题。太长不看版如下：支持多环境与Pipenv的（因此也是Pipfile的）对不同应用环境可重用的理念背道而驰。所以如果你想对库使用Pipfile，那你运气不太好。这意味着许多项目不能使用Pipenv进行依赖管理。

细述的版本是关于Kenneth Reitz（Python社区中的令人惊奇的一部分，以及我的个人灵感）的过度直率和对社区需求不够开放的态度。我建议彻读1050号问题以便对此事形成自己的看法。虽然他的做法是可以理解的，但也可以理解为什么有些人觉得Pipenv很糟糕。尽管我也讨厌这样，但实在没办法脱离评论作者来评论Pipenv，由于我会再次提到Kenneth，我先提前道歉。

稳定性问题

不幸的是，我不止一次地经历这样的事：明明前一天还运行得很好的测试在第二天工作时报错了。这一般都是Pipenv造成的问题。虽然该团队几乎总能快速解决问题，但如果我们因此遇到很大的bug并不得不部署修补程序，我们的品牌形象将会受损，而我们没多少时间来定位问题所在，只能将Pipenv固定至以前的版本以希望它能正常工作。

如果这些是正确发布过程中的必经的错误，我不会太苛刻，然而事实是发布程序本身就有问题。因为根本没有所谓的发布程序。Kenneth（这里是第二次提到）经常会在主分支上连续修改并提交。我们也经常做这样的事，连续进行十来次修改并提交或者恢复之前的更改。然而，我们并不是所有人都是在维护一个拥有将近11000颗星的GitHub项目，这还是一个每月170000次下载的项目，也是一个由python.org正式推荐的项目。我们都知道，依靠这一工具的人还是挺多的，而且很多人是不得不依靠的。

下一次出现这样的另一个问题时，我只会将Pipenv固定在最后一个工作版本上，我应该从一开始就这样做，直到我被迫更新。

优点

Pipfile和Pipfile.lock确实优于requirements.txt，很大程度上。
虽然我一开始不喜欢它，但在单个工具中内置flake8和安全检查非常棒
从私人存储库（指定）安装非常有效。在Pipfile中指定存储库而不是在系统中的某处替换一个dotfile文件很方便
创建一个新的Pipfile非常简单
向Pipenv新用户介绍很容易
安装索引、git库的混合体很容易...
通过--sequential，它实际上是确定性的，正如宣传的那样
Virtualenv更容易理解
依赖可以安装到系统中（例如在Docker中）——正如我们的案例
团队中从未有人建议不用Pipenv——这一评价实际已经挺高的了

结论

Pipfile并不完美，我不知道它会不会逐渐完美，但我对它感到还算满意，并且我将它推荐给其他团队。但是，我不认为pipenv是最终目标。

作为一个社区我们需要一个适用于库和应用程序的工具。而这正是Pipenv特别不想成为的。Python社区最需要的是做出选择（2还是3）。正如Python之禅所说：“应该有一个——而且最好只有一个——显而易见的方法。”如果我们最终有多种工具用于多种目的，人们总会滥用所有这些工具的，无论如何，事情并不会很美好。