首发于Python之美

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

最后一篇关于Pipenv的讨论了 [捂脸],反正以前我看到这种回应标题就躲了...

还是先回应 @李辉 说的几点,再加点我的感受

KR 有没有借 PyPA 之名来做背书?

python.orgpackaging.python.org的关系我没研究过,是不是道德问题我无从得知,无意翻了下,也找到一个commit

emm,几句题外话.. 讨论Pipenv即可,不要上升到对开发者的攻击。KR的人品基本不会影响我决定是否用他的作品。我上篇文章维护他(我一贯都是这样,希望读者看到是一个美好一些的世界,KR又不会来知乎回应一下,这就有点不公平了),大致是因为我之前从他身上获益很多,如 python-guide、requests、pep8.org 等等,他也给很多好的开源项目贡献过自己的代码: 至少花了时间愿意帮助别人,至于他负不负责、性格如何是他自己的选择,我尊重。

如果确实看不惯他,他的一切东西都可以绕过。但我觉得不至于吧

Lockfile 只要过期就重新生成是合理的吗?

写程序的乐趣之一是每个人都有自己实现一个东西的方案,对我来说Lockfile只要过期就重新生成是合理的。

而Pipfile和Pipfile.lock文件的问题,在我文章讨论区有更详细的解读,有兴趣的可以看看。当我不能改变pipenv设计,我会说服自己尝试理解和接受他,不过最终认为最好的还是yarn的效果,然后接受不了我用回了 requirements.txt,也蛮开心的

文中提到的 requirements.in 学习了。哎,这就是讨论问题的好处,有个观点不确定但放在心里是不对的,要记得拿出来交流,我们这么一讨论,很多人在评论区也说自己的习惯和实践,理越辩越明,我对pipenv了解的又深了一些。

但是:

按照 KR 自己的解释,Pipfile 对标的是 requirements.in,Pipfile.lock 对标的是 requirements.txt:

这句我没有找到KR在哪里说的,没有留演讲链接。欢迎留言区发出来...

粗看了下pip-tools文档。requirements.in就是想要解析的源文件,用pip-compile --output-file=requirements.txt requirements.in可以生成requirements.txt。后端这么做的不多,前端看其实就是 Vue -> Javascript 文件嘛

所以我还是觉得如果对版本敏感就应该在Pipfile写死版本。这个不重要,我可能被pipenv洗脑: 这个问题出现了这么久,想必就是它认为这是应该成为的样子

Poetry 分析依赖慢

嗯,我在公司的电脑上试了下,Resolving花了12s,还算可以接受。不过看这几篇文章的讨论区有人提到它不稳定,特别的具体我就没有经验了,如果谁经验多欢迎写篇文章分享下。

晚上回家我再试试: 我家100M光纤,不知道发生了什么...

星星

我非常看重星星和未处理的Issue/PR情况。pip、virtualenv、setuptools甚至CPython之于其他编程语言Star都很少。但是我都会用,很简单: 官方的,无可替代的,不好也得忍着。「官方的项目」往往星星都不多,但是有人在背后能(虽然做的不一定好)做强有力支撑我心安。

如果谁也靠不住,我自己搞一个: 我也信我自己

总结

好啦,最后说几句。我在知乎从来不参与任何热点事件,也不对自己不熟悉的领域发表观点。

当在一个领域里面有了一些成绩,写书、开专栏、开Live等等之后,会积累很多订阅者或者说粉丝。这个时候观点和言论会影响到很多人,我觉得还是多宣传Python世界美好的一面吧

编辑于 2019-09-02

文章被以下专栏收录