• 对Pipenv的一些使用心得
  • 发布于 2个月前
  • 225 热度
    0 评论
  • 核桃酥
  • 3 粉丝 36 篇博客
  •   
如果你没有在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之禅所说:“应该有一个——而且最好只有一个——显而易见的方法。”如果我们最终有多种工具用于多种目的,人们总会滥用所有这些工具的,无论如何,事情并不会很美好。
...Poetry呢?
我也希望我知道。自从我开始着手我们团队现在的(GDPR相关)项目以来,我没有太多时间再实验了。但它看起来确实挺不错的。
用户评论