回应《也谈「不要用 Pipenv」》

看了董伟明老师（

董伟明

）的《 也谈「不要用 Pipenv」》，这篇文章对其中的一些观点作出一些回应和解释。

也看了 Frost Ming 老师（

岂不美哉

）的《 Pipenv 有什么问题》，很感谢他作出的努力，祝 Pipenv 早日脱离 Kenneth Retiz 的影响，愈来愈好。

（Kenneth Retiz 下文简称 KR）

KR 有没有借 PyPA 之名来作背书？

因此做者并无想着用来背书。

我仍然认为 KR 有利用 PyPA 作背书，甚至在误导别人 Pipenv 是 Python 官方（混淆 PyPA 和 Python 官方的概念）推荐的工具。

证据 1

2017 年 8 月 29 号，在 Pipenv 还不够成熟的时候，PyPA 成员 Thea Flowers 建立了一个 PR 要把 Pipenv 添加到 PyPA 的打包教程里，介绍使用 Pipenv 安装和管理依赖（注意这时候 Pipenv 根据教程的内容在 Windows 上是无法正常使用的，具体见 9 月 2 号的这个 issue）。

2017 年 8 月 31 号，Thea Flowers 本身合并了 PR。注意这个教程页面是临时的单独页面，尚未正式放到打包教程的页面里。

2017 年 9 月 1 号，KR 在 Pipenv 的 README 里加了这样一行介绍语：「Pipenv — the officially recommended Python packaging tool from Python.org, free (as in freedom).」（commit）

其中的关键内容翻译过来大概是「官方推荐的 Python 打包工具，来自 Python.org」。

仅仅由于在 PyPA 的打包文档里加入了一个短教程（其中介绍了使用 Pipenv 安装和管理依赖），而后 KR 就在 Pipenv 的介绍里宣传这是「官方推荐」，而注明的官方来源则是「http://Python.org」，这两个关键词背后的超连接都是 PyPA 打包文档的 Pipenv 介绍。packaging.python.org（PyPA） 和 python.org（Python 官方） 的区别很大，很明显，他清楚二者的区别，但又故意没有表达清楚。

退一步讲，无论他的意图是什么，这样的措辞都会让人觉得是 Python 官方推荐的打包工具，尤为是对 PyPA 这个组织不了解的人，看到 Python.org 都会认为是 Python 官方。

证据 2

在 PyCon 2018（五月），KR 在演讲《Pipenv: The Future of Python Dependency Management》里介绍 Pipenv 的卖点的时候，列在第一条的仍然是上面那一句「Officially recommended tool from http://python.org」：

和在 README 里不一样的是，此次在演讲上别人无法去点那个 python.org 的连接去甄别到底是 python.org（Python 官方） 仍是 packaging.python.org（PyPA）。而 KR 在介绍这里的时候没有任何说明，直接说是「来自 Python.org 的官方推荐」。

至于 KR 和 PyPA 或者说和 Thea Flowers 有什么关系？把 Pipenv 的介绍加到打包文档是 Thea Flowers 的我的意愿？仍是 PyPA 的 35 个成员所有赞成的结果？是什么促使 PyPA 在 Pipenv 还不成熟、甚至教程里的内容无法在 Windows 上正常操做的状况下添加到打包教程里？这些问题我暂时找不到答案。

（注：PyPA 指的是 Python Packaging Authority，一个负责维护 Python 打包相关的库（好比 pip、virtualenv 等）和文档的组织。）

从 0 升到 18 的措辞问题

而所谓的 18.X.X是 calver versioning(基于日历的版本)

在上一篇文章里，我引用了一段 HN 上的评论来归纳 Pipenv 在推广方式上的问题：

Kenneth Retiz 滥用他在 PyPA 的位置（并且快速把一个其实是 beta 状态的产品的版本号从 0 升到 18）来暗示 Pipenv 已经很是稳定，受到大力支持而且很是官方，但事实却并非这样。

这句话的英文原文是：

However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was.

其中关于版本的部分是「and quickly bumped a what is a beta product to version 18」，多是我乱翻译形成了误解……我认为原文里的 18 就是一个夸张的表达方式，把这里的数字换成 100 也能够表达一样的意思（也多是指 0.3.0 跳到 3.0.1 那次）。换用日期版本号（CalVer）那次看起来没什么问题（11.10.4 -> 2018.05.12），因此我认为这里的 18 和日期版本号不要紧。

Lockfile 只要过时就从新生成是合理的吗？

> Kenneth Reitz 先是说 lockfile 只要是过时了就老是会被从新生成
这是对的，Pipfile和Pipfile.lock是对应的，当执行 pipenv install后改了Pipfile，对应的Pipfile.lock就必定会改。错误的是，不该该改那些不相关包的版本: 既然已是 ==的了，就代表肯定了具体版本呀。
这些问题， 其实源于 Pipfile对应依赖在一开始没指定具体版本，也就是Pipfile对标requirements.txt，而Pipfile.lock只是当前环境的一个「快照」，若是Pipfile没有明确版本就用Pipfile.lock里面指定的。

个人主要想法是这样的功能实现是不合理的。Pipenv 在安装一个包的时候默认就使用通配符（*）版本写到 Pipfile 是不合理的设计。这样的设计不符合正常的开发流程和使用习惯。若是我在安装一个包的时候就要明确本身要安装哪一个版本，以便在 Pipfile 里固定版本，这样会很不方便，并且让 Pipfile.lock 的存在乎义变得很弱。

按照 KR 本身的解释，Pipfile 对标的是 http://requirements.in，Pipfile.lock 对标的是 requirements.txt：

按照大部分人的理解，Pipfile 是全部不固定版本的高层依赖的列表（unpinned），而 Pipfile.lock 是固定安装时采用版本的详细依赖列表（pinned），用来复现程序具体的依赖环境；除非我主动执行 update 命令更新某个依赖，不然 Pipfile.lock 不该该被改动。但实际的 Pipenv 并非这样，更新 Pipfile.lock 变成了频繁发生（install/uninstall/update）的默认行为。

Poetry 分析依赖慢

Resolving dependencies... (422.9s)
安装个包7分钟，这... 谁能忍？大家试试把bluelog项目的依赖用 poetry add加一遍须要多久？我反正体验不下去了

实际测试安装 Flask-SQLAlchemy，解析依赖花了 42 秒（Windows+代理），没有 7 分钟那么夸张。由于解析依赖的结果会被缓存，我就在另外一台 Mac（代理）上也试了一遍，结果只花了 8.3 秒。多是网络情况的问题？

另外我试了把 Bluelog 的全部依赖一次性安装（Windows+代理），其中解析依赖只花了 16.8 秒（由于解析结果缓存的缘由，实际也许会稍久一点）：

$ poetry add flask flask-ckeditor flask-mail flask-sqlalchemy flask-wtf flask-moment python-dotenv bootstrap-flask flask-login flask-debu gtoolbar gunicorn psycopg2 flask-migrate
Using version ^1.1 for flask
Using version ^0.4.3 for flask-ckeditor
Using version ^0.9.1 for flask-mail
Using version ^2.4 for flask-sqlalchemy
Using version ^0.14.2 for flask-wtf
Using version ^0.9.0 for flask-moment
Using version ^0.10.3 for python-dotenv
Using version ^1.0 for bootstrap-flask
Using version ^0.4.1 for flask-login
Using version ^0.10.1 for flask-debugtoolbar
Using version ^19.9 for gunicorn
Using version ^2.8 for psycopg2
Using version ^2.5 for flask-migrate

Updating dependencies
Resolving dependencies... (16.8s)复制代码

因此 Poetry 或许没那么糟糕（固然我还没深刻使用过）。

星星

虽然不是决定性的，可是对于这Star不到6K的项目来讲我是不敢用的

Pipenv 的 Star 的确不少（并且 README、文档甚至代码里处处都是星星✨），KR 但是个营销专家，但项目质量却并无那么好。反正我如今一看见星星和蛋糕就有点头疼。

✨🍰✨

另外，顺便说一句，pip（5627）、virtualenv（3189）和 setuptools（883） 的 Star 数量都没到六千……

好吧，我认可最后这两段是在抬杠 :D