分类目录归档：技术笔记

Flask 已死，FastAPI 永生

7条回复

好险，刚刚要写一个新项目，执行了 pip install flask。等得无聊所以打开了知乎，突然看到首页推荐的这篇《Flask 已死，FastAPI 是未来》。看到一半吓得我赶紧按下 Ctrl-C，然后重新执行了 pip install fastapi。好快！不愧是 FastAPI，连安装都这么快。

Flask！Flask！你怎么了？Flask~Flask~你不能死呀！我跟你相依为命、同甘共苦了这么多年，何况我的书还没有写完，想不到今天白发人送黑发人……

咳咳，说回正题，2021 年我写过一篇《请不要把 Flask 和 FastAPI 放到一起比较》。不是同一个等级的框架拿到一起比较没有意义。这篇《Flask 已死，FastAPI 是未来》从一开始的标题就是错的。

除了比较上的问题，上一篇文章里最后提的问题现在有答案了吗？

各种对比文章贴出来的 hello world benchmark 对于开发生产应用来说有多大的意义？这里的 benchmark 背后有没有任何的 hacky？异步是否等同于高性能还是要看情况？框架本身的性能在一个请求处理流程中占多大的影响？asyncio 的生态怎么样？

同时我也指出了一些 FastAPI 的问题——现在 FastAPI 营销至上的项目运作方式改变了吗？

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

如果一个人即没有深入了解 Flask，也对 FastAPI 的整体状况一知半解，然后突然跳出来写了一篇《Flask 已死，FastAPI 是未来》，他的目的是什么？炒作啊，朋友。标题党也就罢了，到处都是逻辑漏洞和事实错误这也行？

精彩片段赏析

前两天在 Twitter 上对这篇文章发了一点想法。大概是我的语言能力退化，导致很多人没看懂我的反讽和调侃……所以还是好好说话，摘评几条原文的内容：

其实我这篇文章，也可以叫做「Django和Flask之死」，但是在框架应用场景角度来说Flask和FastAPI对比更合适，而Django直接和FastAPI相比有一些差别。在一些商业场景(例如CMS)Django依然是首选，而Flask(甚至FastAPI)看起来更像个「玩具」，所以Django短时间不会被取代(Flask这些年不是也是没取代的了嘛)。
Django REST Framework(DRF)
Django主旨是为了在后端生成 HTML，而不是创建现代前端（如 React、Vue.js ）或与其通信的其他系统使用的 API。所以FastAPI其实和Django REST Framework直接对标，它们主要场景都是构建 Web API，但是名字上也可以看出来，DRF还是依托于Django框架，所以缺点一样。

既然作者能看出来 Django 和 FastAPI 有差别，也了解「FastAPI其实和Django REST Framework直接对标」，那么就看不出来 Flask 和 FastAPI 在框架应用场景角度有差别？所以为什么不用 APIFlask 这种和 FastAPI 对标的框架，而是挑了 Flask？

Flask本来的优点是灵活性和极简主义，但这意味着很多很多组件需要自己造，这个要不然需要公司够大专门有开发者开发和维护，要不然得个人能力极强，否则插件很难达到生产级别，这就造成Flask的第三方插件质量层次不齐，且无法保证长期维护。就像我上面说的那些库，现在来看，其中已经很多不再维护了。

这点蛮中肯，Flask 扩展的质量和维护状态确实参差不齐，这也是为什么我要发起濒危 Flask 扩展拯救计划并创建这个 Flask 扩展状态监控项目。那请问 FastAPI 呢？首先 FastAPI 是否有这么多「FastAPI 扩展」可用？其次 FastAPI 的第三方插件就不会出现这些问题？说到底这是所有开源项目和社区生态都会遇到的问题。

所以即便是今天，你想用Flask构建一个API服务，还是要东拼西凑各个组件，其中某些组件有些没及时更新的地方要自己动手解决，这对于老手来说还好，对于新人来说很痛苦，尤其是你想要应用现在最新的实践方案和理念，只能望而兴叹。

首先作者了解 Flask 和 FastAPI 相比，后者的主要场景是「主要场景都是构建 Web API」，接着又说 Flask 生态构建 API 需要东拼西凑。听起来不太对劲？

另外 Flask 生态中类似 FastAPI 这种提供 API 整体解决方案的框架都被作者忽略了？随便列几个：

东拼西凑就一定是缺点？不熟悉这些工具的人选择打包方案，熟悉的人选择自己组装，这有什么问题吗？

这个时候Flask并不想接受改变，社区迟迟的不加入aio的支持，另外Flask原作者也去写rust了，把项目交给了2个维护者（现在只剩一个人了)。

到这里文章就开始有些不对劲了，喜剧/戏剧效果逐渐增加……Flask 开始被拟人化了。Flask 是谁？是谁要求改变？Flask 说了啥表示不想改变？

Flask 作者把项目交给了 2 个维护者？现在只剩一个人了？！Flask 真的好惨……可是这些事情都是什么时候发生的？虽然我最近两年开始工作已经没怎么给 Flask 提交代码，不知道哪天被踢出群聊。但是至少我从 18 年到现在一直是 Flask 的维护者，这些事情我怎么一点都不知道？

在Flask的那个时代，代码执行是单线程、同步的，这意味着要依次处理请求，前一个请求完成前，其他请求消耗在等待 I/O 操作上。而asyncio是最好的解决方案，它让I/O成为异步操作，无需等待任务完成即可获取任务结果并继续处理其他任务请求。

好奇 Flask 的那个时代是哪个时代呀？听起来像是妈妈在讲小时候的故事呢。Flask 2.0 已经添加了有限的 async 支持。Quart （Flask 的 ASGI 实现）已经合并到 pallets 组织，作者正在推动 ASGI 支持的 Flask。这些都是这个时代的 Flask 在发生的事情哦。

而FastAPI天生支持并发和异步代码，代码写对了就可以在效率上达到极致，所以它被认为是目前最快的Python框架，效率和NodeJS或Go接近。当速度和性能至关重要时，FastAPI 是最佳选择。

嗯，这个我无从反驳。你说快就是快，宇宙最快 Web 框架。

另外由于集成了Pydantic，所以非常容易在项目中添加ORM（如SQLAlchemy），从请求中获得的对象可以直接传递到数据库，因为已经做过数据验证。反之亦然，可以将从数据库获取的对象直接返回。
相对的，Flask这方面的缺失的。

完蛋，Pydantic 对 Flask 发起了单方面安装制裁。当你在 Flask 项目里试图引入 Pydantic 的时候，就会出现安装错误“Warnning: Pydantic is strictly forbidden to installed into a Flask project. Your behavior has been reported to PAFAFC (Pydantic and FastAPI and friends Committee).”

再补充一点。FastAPI无论看项目名字还是介绍都能感觉出来它是用于构建API服务的，事实上FastAPI自己的核心代码也确实是这样的，可以说它不是一个传统的、完全自己实现的框架，它更像是一个集各家之长的框架，从一个空壳开始，把需要的、适合的组件组装起来。例如它没有模版引擎，如果你确实需要用它实现一个web应用要渲染模版，你可以再组合你想要的选择，当然还可以用Starlette内置的Jinja2（是的，也是Flask内置的）。

作者对于 Flask 和 FastAPI 两者定位不同的认识真是越来越清晰了呢。不过「组合我想要的选择」不就变成前面说的 Flask 那样东拼西凑了嘛，不好。还有就是 FastAPI 为啥要在介绍模板引擎的文档里让我安装 Jinja2 呢？看来「相对的，FastAPI这方面是缺失的」。

上面提的是FastAPI的优势，但是也不能说明Flask已死，我为什么会这么觉得呢? 主要还是看开发者和用户的人气。

重头戏来了，下面终于到了对于「Flask 之死」的凄惨景观的详细描写（注：这几点后来作者看到了我在 Twitter 上发的东西又自己做了补充和修改。这里我引用的是原文）。

1. 社区活跃度。例如项目的Issue和Pull Request数量，Flask都是个位数，和FastAPI相比根本不是一个水平。这其实侧面证明项目不再活跃，因为如果活跃的话，老的用户会有更多需求，它们不来说明已经离开，而新的用户意味着有各种问题，文档即便足够全，其实我们要知道还是会有很多用户来提问和贡献代码的，没有就说明用得少。

如果你经常参与开源项目或是自己开发了开源项目，通常会了解到，一个流行的项目想要把所有的 issue 和 pull request 都处理掉是很难的事情。而 Flask 能做到这一点反而是维护团队的努力尽责和项目本身足够成熟的体现：

blank

以及对 issue 和 pull request 快速响应的体现：

blank

如果你想知道有多少人在用 Flask 和 FastAPI，有两个参考数据，一个是 GitHub 上开源项目的用户数量统计。这些可以在两个项目的 GitHub 主页直接看到。

FastAPI：

blank

Flask：

blank

另一个数据是 PyPI 下载量，这个可以在 PyPI Download Stats 上看到。

FastAPI：

blank

Flask：

blank

另一方面，不同的项目对 issue 的使用策略是不同的。有的使用自己的 issue tracker，有些鼓励用户来提问。Issue 和 pull requests 不仅不能用来表示项目活跃度，过多的数量反而能说明一个项目的维护状况堪忧。堆积的 PR 对于用户和开发者来说都是灾难。以 FastAPI 为例，你看看现在的 PR 列表里都是什么？项目不如改名叫「FastAPI 文档大全」好了。你觉得这样会让提交代码贡献，修复 bug 的人有很好的体验？

blank

FastAPI 有不少 issue 在建议作者创建开发团队，摆脱当前这种低效的维护模式。类似的抱怨有很多，我不想去翻历史，这里仅以置顶 issue 里的一则回复举例：

blank

评论中提到的是这个 PR。一个 bug 在 2022 年就有人试图修复，但是到现在都没有被处理。而且报告相关 bug 的 issue 已经被转换成讨论。最后一条是用户在建议把这个讨论转换回 issue：

blank

没错，FastAPI 本来有几百个 issue（好活跃，对吧），某个时间点被批量转换为讨论，谁知道里面有多少是没有被处理的 bug report。谁知道这 646 个 PR 里有多少是需要被优先处理的 PR。我在 2020 年也提议把文档翻译放到单独的仓库，后来这个 issue 也被转成讨论了。到现在贡献者依然被这个问题困扰：

blank

2. 讨论度。也就是博客文章，Stackoverflow等网站咨询和讨论的热度，其实可以感受到，已经没什么人写Flask相关的内容了。

作者写文章是可以随口就来的？博客文章不好统计，那么以 Stack Overflow 来看。抛开问题总数量，因为两个项目创建时间不同。但就提问频率，以上次发推文和现在两次截图的数据来看，和 Flask 相关的问题都创建的更频繁。

FastAPI：

blank

Flask：

blank

3. 开发迭代的频率。翻一下commits，可以看到Flask只有一个维护者会偶尔修修bug，没有什么大的功能特性开发。

开发迭代的频率和活跃度也是作者强行建立的联系，不过结合 FastAPI 的运作方式，两位作者倒也是「双向奔赴」了。「偶尔修修bug，没有什么大的功能特性开发」有什么问题吗？这就是维护者应该做的事情，大的功能特性又不是每天都有。而且作者是不是没有看 FastAPI 的 commits 历史？你肯定猜不到三千多个 commits 里有一千多是 bot 在更新 changelog。再猜猜 FastAPI 最新一个 release 都有哪些新功能？11 个改动里有 5 个是在更新 README 上的赞助商列表哦：

blank

4. 灵魂人物的影响力。Flask的灵魂人物，也就是项目的发起人其实早就不再参与项目了，搜一下项目贡献记录可以看到Armin Ronacher上次参与开发已经是6年前了。

这条实在不知道说什么好。我创建了项目我就得绑死在项目上直到生命最后一刻是吗？引用一下我在 Twitter 上的回复：

开源项目一定不要创建 GitHub org，项目再流行也要放在自己的账号下。不要成立什么开发团队，PR 要自己慢慢 review，用户抱怨多了，你自然知道哪个 PR 比较重要。还有就是用自己的账号或头像来设置 bot，这样即使你哪天兴趣转移了，用户会以为你一直在参与。斯人已去，灵魂犹在。

我真的佩服 FastAPI 作者这一招用自己的账号来作为 bot，用户以为你在活跃，而这个 PR 哪天能够被 merge 还要多烧几炷香：

blank

一边说自己忙得不行，一边又坚持把项目放在自己个人账号下，坚持自己 review PR。这就是灵魂人物？

后记

终于写完了。没想到只是偶然在一台没有屏蔽推荐首页的电脑上打开了知乎，最后要浪费这么多时间和精力。我想肯定会有人看了开头就急着评论，说「FastAPI 如何好用」或是「Flask 如何不好用」甚至是「Python 不如 XXX」。这些都是离题的讨论，我不完全否认这些观点，也并没有谈及这些。这篇文章只有两个目的：

  • 强调不应该把两者放到一起比较
  • 指出那篇「引战文」中的错误观点和事实偏差，顺便指出一些 FastAPI 的问题

对于程序员来说，你可以使用任何框架，你也可以使用任何编程语言。程序员不就是要随时接受改变，随时学习新的东西吗？没人要你一辈子只能用 Flask 或是 Python。另一方面，即使别人都用 FastAPI 了，我用 Flask 又会怎么样？工具而已，只是按照需要做出适当或喜欢的选择。但是你起码要看一看文章再发表评论，而且也不用看到什么观点就相信什么观点（尤其是没有论据、结论先行的文章）。

同时建议 FastAPI 推介者保留一点体面。新事物的建立不一定要踩在已有事物的坟墓上。挑起对立只会导致 Python 社区的混乱。最后再引述我在上一篇文章的想法作结：

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

相关链接

如果你在 macOS 上无法访问 Flask 程序

发表回复

如果你用 macOS 开发 Flask 时无法正常访问程序，或是使用 ngrok 等内网穿透工具时映射的公网地址无法访问，大概率是因为 macOS 新版本（Monterey）的变动导致。你会在页面上看到类似下面的错误信息：

Access to 127.0.0.1 was denied.

You don't have authorization to view this page.

HTTP ERROR 403

或是在执行 flask run 命令时看到类似下面的报错：

OSError: [Errno 48] Address already in use

首先确认你的 macOS 版本是不是 Monterey（左上角 Apple 图标 – About This Mac）或是之后的版本，如果不是那么问题应该和本文无关。

简单来说，新版本的 macOS 上 localhost 5000 端口被一个叫 AirPlay Receiver 的服务占用了。而 Flask 内置服务器默认就运行在 5000 端口，所以会造成端口冲突。当你通过将 host 设为 0.0.0.0 指定 Flask 的内置服务器对外可见，或是使用内网穿透工具时，会发现程序无法访问（有时未设置对外可见也会遇到这个问题）。

最简单的解决方法是关掉这个服务：

  • 系统设置（System Preferences） > 分享（Sharing） > AirPlay Receiver > 取消勾选

或是更改 Flask 开发服务器默认的端口（比如改成 8000）。在执行 flask run 命令时使用 -p/–port 选项可以自定义端口：

$ flask run -p 8000  # 或 flask run --port 8000

或是在执行 flask run 之前通过环境变量 FLASK_RUN_PORT 设置：

$ export FLASK_RUN_PORT=8000 # macOS/Linux
> set FLASK_RUN_PORT=8000 # Windows CMD
> $env:FLASK_RUN_PORT=8000 # Powershell

在 Werkzueg 2.1.0（2022/3/28 发布）版本，如果你执行 flask run –host=0.0.0.0 时检测到了端口被占用，会直接显示相关的错误提示：

$ flask run --host=0.0.0.0
Address already in use
Port 5000 is in use by another program. Either identify and stop that program, or start the server with a different port.
On macOS, try disabling the 'AirPlay Receiver' service from System Preferences -> Sharing.

本文源于去年十一月发的一条推文，最近经常碰见有人遇到这个问题，所以转成这篇文章发出来。

画了一幅涂鸦，送给苹果公司：

blank

请不要把 Flask 和 FastAPI 放到一起比较

12条回复

The war has begun. Let’s end the war between Flask and FastAPI.

去年在知乎上看到一篇文章，后来想找却找不到了，最后通过关键词「5 分钟」和「四年」在掘金上找到了原文——《用它5分钟以后，我放弃用了四年的 Flask》。作者先是给出了一个手动用 if 验证请求数据的 Flask 视图函数：

@app.route('/insert', methods=['POST'])
def insert():
    info = request.json
    name = info.get('name', '')
    if not name:
        return {'success': False, 'msg': 'name 参数不可省略，不可为空！'}
    age = info.get('age', 0)
    if not isinstance(age, int):
        return {'success': False, 'msg': 'age参数不是数字！'}
    age_after_10_years = age + 10
    msg = f'此人名叫：{name}，10年后，此人年龄：{age_after_10_years}'
    return {'success': True, 'msg': msg}

然后给出了一个使用 Pydantic 编写数据模型类 + FastAPI 路径操作函数的代码：

class People(BaseModel):
    name: str
    age: int
    address: str
    salary: float
    
@app.post('/insert')
def insert(people: People):
    age_after_10_years = people.age + 10
    msg = f'此人名字叫做：{people.name}，十年后此人年龄：{age_after_10_years}'
    return {'success': True, 'msg': msg}

通过这两段代码进行对比，文章作者得出结论「我用了 Flask 四年，但在使用了5分钟 FastApi 以后，我决定以后不再使用 Flask 了」。你确定你用了四年的是 Flask 而不是 Flash？在此后的很长一段时间里，经常看到类似的对比和结论，所以我打算用这篇文章来澄清这个非常普遍的误解。如果看到有人把 Flask 和 FastAPI 放到一起比较，请把这篇文章的链接丢过去。

利益相关：笔者系 Flask 维护者和 APIFlask 作者。本文观点仅代表个人看法，与 Pallets 团队无关。

为什么 Flask 和 FastAPI 不能放到一起比较？

我在此前介绍 APIFlask 的文章里一开始就提到过这件事情：

经常看到有人把 FastAPI 和 Flask 放到一起比较，但是却没有意识到这完全是两种东西——前者是基于 Web 框架 Starlette 添加了 Web API 功能支持的（框架之上的）框架，而后者是和 Starlette 同类的通用 Web 框架。你怎么能让小明和骑电动车的小军赛跑然后还夸小军好快好强？

前两天看了 Reddit 上 Flask 2.0rc 帖子下的很多回复，预感到在 Flask 2.0 发布后在中文网络上也许会出现许多类似的问题和讨论，所以想着还是值得单独写一篇文章来谈这件事。

受那个 Reddit 主题里某个评论启发，想到一个更好的比喻： Flask 和 FastAPI 就像是苹果和橙汁。你不能把苹果和添加了更多蔗糖和添加剂的橙汁放在一起比较哪一个更甜。苹果（Flask）应该和橙子（Starlette）比较，橙汁（FastAPI）当然也应该和苹果汁（基于 Flask 的 Web API 框架）进行比较。也就是说，Flask 是一个通用型框架，和 FastAPI 依赖的 Starlette 一样，而 FastAPI 是添加 Web API 支持的二次框架。因此，Flask 应该和 FastAPI 所依赖的 Starlette 进行比较，而 FastAPI 应该和基于 Flask 的 Web API 框架进行比较。

同理，FastAPI 也不能和 Django、Tornado、web2py、Bottle、CherryPy、Pyramid、Sanic 等通用型 Web 框架比较。

更合理的比较对象是什么？

既然「FastAPI 应该和基于 Flask 的 Web API 框架比较」，那么合适的比较对象有哪些？Flask-RESTX、Flask-Rebar、flask-apispec、flask-smorest、Flask-RESTful、APIFairy 这些虽然试图做成框架，但在具体实现上仍然是 Flask 扩展，所以真正公平合理的比较对象是：

这三个框架都是基于 Flask 实现的 Web API 框架。不过 Eve 没有内置 OpenAPI 支持，而 Connexion 是一个 Spec-First 框架，也就是 OpenAPI spec 优先（先编写 spec，然后生成项目基础代码进行开发）的框架。因此，尽管 APIFlask 只是一个刚发布没多久的实验项目，但它是最适合和 FastAPI 进行比较的项目。

FastAPI 和 APIFlask 有着同样的组成结构，都是作为一层胶水粘起来一个 Web 框架和一个数据序列化/验证库，然后加一点 Web API 功能支持：

在主要功能上也有很多交集：

  • 自动反序列化和验证请求数据，自动生成错误响应
  • 自动格式化和序列化响应数据
  • 自动生成 OpenAPI specification 文件
  • 自动生成交互式 API 文档

当然，相对于发布已经三年的 FastAPI，APIFlask 还只是一个三个月大的新项目，还有很多地方需要改进和完善。如果你对 APIFlask 感兴趣的话，可以在这篇文章了解详细介绍或是在它的 GitHub 仓库查看源码。

为什么会有这样的误解？

为什么会有那么多人把 FastAPI 和 Flask 放到一起比较？在我看来有三个原因：

首先是 FastAPI 采用了和 Flask 类似的装饰器路由，很容易让人联想到 Flask。

二是 FastAPI 没有给它的项目构成做足够的说明。如果 FastAPI 在其介绍的第一句就加上「based on Starlette and Pydantic」而不是放到 Requirements 部分才提及，这样也许会让 Starlette 和 Pydantic 获得更多应有的关注，也就不会有这么多人拿 Flask 和它比较。

再就是 FastAPI 的推介者对 FastAPI 了解的不够多。不清楚它的项目结构，自然就不了解它和其他 Web 框架的区别。而介绍时为了带来足够的吸引力，推介者常常选择拉上和用户量足够大的「竞品」进行对比这种方式，所以才会有大量类似本文开头提到的那种文章。这些文章甚至完全没有提及 Starlette 和 Pydantic，只是一味强调「这是一个超高性能的、碾压 Flask 的框架」。

FastAPI 不是银弹

FastAPI 只是说它能把「功能开发速度提升约 200% 至 300%」，距离十倍还差了一些，自然不能算是银弹。但是这两年看到了很多对 FastAPI 的盲目吹捧，仿佛 FastAPI 就是完美的解决方案。这也许都要归功于 FastAPI 在其 README 和文档里「大胆」的措辞和承诺以及不厌其烦的特性介绍。举例来说，如果它只是说「Very high performance, it is comparable to some frameworks in Go and NodeJS」，那么用户也许就会认为「和 Go/NodeJS 有一拼」，但是说成「Very high performance, on par with NodeJS and Go」，那么用户就会想「和 Go/NodeJS 不相上下」（以至于中文翻译是「可与 NodeJS 和 Go 比肩的极高性能」），这当然会带来一些争议。再比如，如果只是说「double or triple the development speed」，那么用户大概会想「效率还不错」，但是它用了「Increase the speed to develop features by about 200% to 300%」，数学不好的用户就会惊呼「哇，提高 30 倍开发效率」。同时这种营销带来的狂热用户，也很容易被煽动去给 Python Steering Council 施加压力——在 Python 3.10 快要发布的时候突然跳出来要求撤销一个 PEP。

这种营销至上的项目运营方式带来的直接后果是糟糕的维护状态。FastAPI 似乎在慢慢变成一个翻译项目，在代码里的文档字符串都还没写的情况下，其用户文档就已经开始扩展到十几种语言。而这十几种语言的翻译和项目源码都放在同一个仓库里，这导致所有开启的近 300 个 PR 里有过半是翻译。issue tracker 和 discussion 不做区分的使用，这导致所有开启的近 600 个 issue 里有九成是提问）。我在此前创建过一个 issue 来反馈这个问题，但并没有得到回应。另外凭个人喜好来说，在每个 commit 信息里都加上 emoji 并不可爱。而每一个 commit 都要触发 bot 更新 changelog，带来的是一份丑陋的 commit 历史（所有 commit 里有三分之一是在更新 changelog）。这些也许是发展社区或是让项目看起来很活跃的有效方法，但很显然这带来的是建立在混乱之上的虚假繁荣。

另外，许多推介文章都会在最后贴出来一张 benchmark 截图来证明 FastAPI 有多么 fast，但是完全不会提及的是：贴出来的 benchmark 对于开发生产应用来说有多大的意义？这里的 benchmark 背后有没有任何的 hacky？异步是否等同于高性能还是要看情况？框架本身的性能在一个请求处理流程中占多大的影响？asyncio 的生态怎么样？

从长远看这些大都是一些临时问题，而且 FastAPI 作者已经开始全职开发开源项目，这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI，吹捧并不能让一个东西变得更好，参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好，也期待看到有更多优秀的 Python 框架出现，但我不喜欢过度炒作、盲目的吹捧和错误的对比。

P.S. Flask 2.0 版本即将发布

顺便说一句，Flask、Werkzeug、Jinja 等 Pallets 项目都将在 5 月 11 日（PyCon 开始）之前发布下一个主版本，主要包含下面这些新特性（完整变动见 changelog）：

  • Flask、Werkzeug 和 Click 添加了 type hints
  • Flask 实现了有限的 async/await 支持
  • Flask 支持嵌套蓝本
  • Flask 添加了快捷版本的 route 装饰器（即 @app.get、@app.post 等）
  • Flask 支持在视图类上使用 route 装饰器（我前两天刚提交了一个 PR 来实现这个功能，暂时不确定是否会被合并，在这先提前说一下 :p）
  • Werkzeug 的 multipart 解析性能大幅提升

你可以使用下面的命令安装 Flask 2.0.0rc 版本进行测试：

 $ pip install --pre flask

欢迎反馈 bug 和提改进建议。关于 2.0 版本的详细介绍将会在发布后另外撰文说明。

延伸阅读

一个困扰我两年的 Flask「Bug」

发表回复

TL;DR 版本：

如果你的程序存储在单脚本里，比如 app.py，那么 .flaskenv 和 .env 应该放在程序脚本的同级目录：

myproject/
    - app.py
    - templates
    - static
    - .flaskenv
    - .env

如果你的程序存储在程序包里，那么 .flaskenv 和 .env 应该放在程序包的同级目录：

myproject/
    - app/
        - templates
        - static
        - __init__.py
        - views.py
    - .flaskenv
    - .env

如果你把 .flaskenv 和 .env 放到了再往上一层（myproject 再往上），或是把你的程序包或程序脚本放到了一个子目录（比如 /myproject/myapp），那么执行 flask run 就会出错。

严格来说算不上 bug，而是一个很容易导致出错的设计。具体行为是，如果你安装了 python-dotenv，同时在 Flask 程序的上层目录创建了 .env 或 .flaskenv 文件，那么你将没法成功执行 flask run 等命令，因为这会导致 Flask 没法正确找到对应的 Flask 程序实例。

这个问题从 Flask 开始引入 CLI 机制开始就存在了，困扰了我两年。18 年偶然在用户根目录创建了一个 .env 文件，发现 Flask 程序没法运行了，当时遇到的各种 bug 太多，没仔细考虑这两者之间的关联。后来经过几次测试，才确定下来是上层目录的 .env 和 .flaskenv 文件导致，但是一时找不到原因，就暂时放下了。直到 19 年 11 月，花了几个小时排查，还是没找到原因。

中间花了很长时间来追踪 Windows 特定的 Flask 程序无法启动的 bug（TypeError: environment can only contain strings），实在是怕了。因为 Flask 的 CLI 涉及太多东西，有时你要钻进 python-dotenv（#101） 和 Werkzeug（#1320） 才能找到问题的原因。

但是问题不解决的话，你永远睡不好觉。《Flask Web 开发实战》第一部分的示例程序都放在了一个程序仓库，而且都放在了子目录，这意味着如果读者错误的在仓库根目录创建 .env 和 .flaskenv 文件的话，就会导致子目录下的六个示例程序没法运行。前后大概收到 6 个相关的读者反馈，虽然后续在网站上添加了提醒，在重印的书里介绍创建 .env/.flaskenv 文件的地方追加提醒，但这终究没有真正解决问题，而且总会有人可以完美的错过所有提示。

如果每个人都可以在书上标记出错位置并共享，那么这一页应该会有很多红色小叉号（参考《超级马里奥制造》，也许未来某个电子书平台会做出来这个功能 :P）。

前几天在这个 Issue 的提醒下，又花了两个小时排查，这次终于找到原因。加上写 PR（#3560）和 Issue（#3561），前后两年一共花了 8 个小时，这个问题终于有了着落。没意外的话，预计会在下一个版本的 Flask 中更新。下面是具体原因。

本来以为这个问题和 python-dotenv 或 Werkzeug 相关，没想到只是 Flask 本身代码的问题，我太笨了，这个问题本可以早一点解决。

按照预定的行为，当安装了 python-dotenv，Flask 会自动加载 .env 和 .flaskenv 里的环境变量。python-dotenv 在搜索存储环境变量的文件时，会从当前目录开始向上搜索，如果找到就返回对应的文件路径。但是这时 Flask 如果发现 .env 或 .flaskenv 的所在目录不是当前目录，就会把当前工作目录切换到 .env 和 .flaskenv 所在的目录（相关源码）。而如果你的程序模块或程序包不是和 .env/.flaskenv 同级目录的话，就会导致找不到程序实例。

使用下面的步骤可以重现：

$ git clone https://github.com/greyli/flask-env-test
$ cd flask-env-test
$ pip install -r requirements.txt  # or just pip install flask[dotenv]
$ cd hello
$ flask run

示例项目的文件结构如下：

- flask-env-test
    - .env
    - hello
        - app.py

像示例程序这样把程序存储在 app.py 文件中时，运行 flask run 你会看到下面的报错：

$ flask run
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
Usage: flask run [OPTIONS]

Error: Could not locate a Flask application. You did not provide the "FLASK_APP" environment variable, and a "wsgi.py" or "app.py" module was not found in the current directory.

如果你使用 FLASK_APP 指定了程序的导入路径，那么错误大概会是这样：

$ flask run
 * Serving Flask app "myapp"
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
Usage: flask run [OPTIONS]

Error: Could not import "myapp".

相关链接

安装 Python 依赖出现 MarkupSafe ImportError … Feature 报错的解决方法

发表回复

这个报错在 3 月 8 号 setuptools 发布新版本之后出现，通常会在安装 Python 依赖时触发。

报错信息

使用 pip 安装依赖时的报错如下：

Collecting markupsafe==1.0
  Downloading https://.../MarkupSafe-1.0.tar.gz (14 kB)
    ERROR: Command errored out with exit status 1:
     command: '...\python.exe' -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'...\\pip-install-bsormril\\markupsafe\\setup.py'"'"'; __file__='"'"'...\\pip-install-bsormril\\markupsafe\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base '...\pip-install-bsormril\markupsafe\pip-egg-info'
         cwd: ...\pip-install-bsormril\markupsafe\
    Complete output (5 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "...\pip-install-bsormril\markupsafe\setup.py", line 6, in <module>
        from setuptools import setup, Extension, Feature
    ImportError: cannot import name 'Feature'
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

使用 Pipenv 安装依赖时的报错如下：

An error occurred while installing markupsafe==1.0 --hash=sha256:a6be69091dac236ea9c6bc7d012beab42010fa914c459791d627dad4910eb665! Will try again.
Installing initially failed dependencies…
[pipenv.exceptions.InstallError]:   File "...\Python\Python36\site-packages\pipenv\core.py", line 1874, in do_install
[pipenv.exceptions.InstallError]:       keep_outdated=keep_outdated
[pipenv.exceptions.InstallError]:   File "...Python\Python36\site-packages\pipenv\core.py", line 1253, in do_init
[pipenv.exceptions.InstallError]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.InstallError]:   File "...\Python\Python36\site-packages\pipenv\core.py", line 859, in do_install_dependencies
[pipenv.exceptions.InstallError]:       retry_list, procs, failed_deps_queue, requirements_dir, **install_kwargs
[pipenv.exceptions.InstallError]:   File "...\Python\Python36\site-packages\pipenv\core.py", line 763, in batch_install
[pipenv.exceptions.InstallError]:       _cleanup_procs(procs, not blocking, failed_deps_queue, retry=retry)
[pipenv.exceptions.InstallError]:   File "...\Python\Python36\site-packages\pipenv\core.py", line 681, in _cleanup_procs
[pipenv.exceptions.InstallError]:       raise exceptions.InstallError(c.dep.name, extra=err_lines)
[pipenv.exceptions.InstallError]: ['Looking in indexes: https://.../pypi/simple', 'Collecting markupsafe==1.0', '  Using cached https://.../MarkupSafe-1.0.tar.gz (14 kB)']
[pipenv.exceptions.InstallError]: ['ERROR: Command errored out with exit status 1:', '
command: \'...\\.virtualenvs\\helloflask-evdb6idn\\scripts\\python.exe\' -c \'import sys, setuptools, tokenize; sys.argv[0] = \'"\'"\'...\pip-install-pkgojp4t\\\\markupsafe\\\\setup.py\'"\'"\'; 
__file__=\'"\'"\'...\\\\pip-install-pkgojp4t\\\\markupsafe\\\\setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' egg_info --egg-base \'...\\pip-install-pkgojp4t\\markupsafe\\pip-egg-info\'', '
cwd: ...\\pip-install-pkgojp4t\\markupsafe\\', '    Complete output (5 lines):', '    
Traceback (most recent call last):', '      
File "<string>", line 1, in <module>', ' 
File "...\\pip-install-pkgojp4t\\markupsafe\\setup.py", line 6, in <module>', '
from setuptools import setup, Extension, Feature', "
ImportError: cannot import name 'Feature'", '----------------------------------------',
'ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.']
ERROR: ERROR: Package installation failed...

其他工具输出类似，主要异常信息是 MarkupSafe setup.py: ImportError: cannot import name Feature。通常会在安装 Flask 项目的依赖时发生，因为 MarkupSafe 是 Flask 的依赖之一。

原因和解决方法

出现这个报错的原因是因为 Python 打包工具 setuptools 在 46.0.0 版本删掉了弃用的 Feature，而 MarkupSafe 刚好在 setup.py 文件里导入了这个类，所以会出现报错。

解决方法很多，最直接的是更新 MarkupSafe 到最新版本（1.1.1），新版本去掉了对 Feature 类的导入。如果使用 requirements.txt 存储依赖列表，那就把 MarkupSafe 的版本号改成 1.1.1（找到 MarkupSafe 开头那一行，替换版本号）：

MarkupSafe==1.1.1

然后重新执行：

$ pip install -r requirements.txt

对于 Pipenv，可以直接执行：

$ pipenv install markupsafe==1.1.1

如果你是《Flask Web 开发实战》的读者，正在为第一部分的示例程序安装依赖，那你还需要执行下面的命令固定 sendgrid-python 的版本（它在新版本添加了不向后兼容的 API 变动）：

$ pipenv install sendgrid==5.3.0

《Flask Web 开发实战》读者备注

如果你在 2020 年 3 月 8 号到 4 月 5 号之间买了《Flask Web 开发实战》，把示例程序克隆到了本地，然后尝试运行 pipenv install 或 pip install -r requirements.txt 命令来安装依赖，那很大概率你会遇到这个问题。

除了使用上面的方法之外，你还可以通过更新本地代码来解决。我最近给所有示例程序的依赖文件做了一次更新，除了书里涉及的 API 产生变动的依赖，其他依赖都已经更新到最新版本。

你可以使用下面的命令来更新你在本地的程序仓库（注意这会重置你对源码进行的修改）：

$ git fetch --all
$ git fetch --tags
$ git reset --hard origin/master

然后重新执行一次 pipenv install 或 pip install -r requirements.txt 即可解决这个问题。如果遇到其他虚拟环境和依赖安装的问题可以参考这篇文章解决。

相关链接：

《Flask Web 开发实战》虚拟环境/依赖/Pipenv 等问题解决方法

1条回复

注：这篇文章的主要受众是《Flask Web 开发实战》的读者。

注2：文中的 $ 符号标识一条命令行命令的开始，$ 前面是当前工作目录，# 号后面是注释。你实际只需要输入 $ 符号和 # 号之间的内容，不包括开头和结尾的空格。

在群聊和论坛里总是看到和虚拟环境和依赖安装相关的各类问题，这篇文章希望能够提供一个统一的解决方案。下次如果遇到有人问虚拟环境/Pipenv/依赖安装相关的问题，请把这篇文章的链接丢过去。

安装 Python 库非常慢？

在进入正题之前，你需要先解决基础设施问题。你在执行 pip install 命令或 pipenv install 等命令时会不会网速非常慢？20k/s 或者干脆看到 Time out，Connection reset 之类的报错，这种情况下，你需要设置 PyPI 镜像。具体操作可以在这篇《从国内的 PyPI 镜像（源）安装 Python 包》看到。

要不要继续使用 Pipenv？

因为书里面在一开始介绍了使用 Pipenv 管理依赖和虚拟环境，同时所有的安装第三方库的命令也都是使用 Pipenv，所以我们要解决的第一个问题是「要不要继续使用 Pipenv？」

我的建议是，如果你在使用的过程中没有遇到过任何报错，那么就继续使用它。直到你觉得它在某些地方不再让你满意。

但是如果你在使用的过程中遇到了问题（首先确保你使用的是最新版本的 Pipenv），比如：

  • 锁定依赖很慢，停留在「locking…」这样的提示不动
  • 执行正确的命令但是总是出现报错

附注 如果你安装依赖时的报错是「MarkupSafe setup.py: ImportError: cannot import name Feature」，请参考这篇文章解决。

那么就继续看下去。

如果不用 Pipenv，我该怎么办？

解决方法和替代工具非常多，这里给出两个。

方法一：不用虚拟环境

最简单的解决方法就是不用虚拟环境。如果你是一个初学者，那么不用虚拟环境完全没问题。现在你把所有的 Python 包全都安装在一个盒子里，你只需要会使用 pip 安装依赖，也就是使用下面的 pip install 命令：

$ pip install flask

附注 顺便说一句，不用虚拟环境时，如果你是使用 Linux 和 macOS 系统的 Python 3 用户，那么执行 Python 和 pip 相关命令的时候需要输入的是 python3 和 pip3，比如：pip3 install flask。后面不再提示。

这个命令会为你安装 Flask。每到需要安装一个包，你就执行这个命令，把上面的 flask 替换成你要安装的包名即可。类似的，书中所有 pipenv install xxx 形式的命令也都替换为 pip install xxx。

这时你可以跳过 Pipenv 和虚拟环境相关的内容。在第一章，当你把当前工作目录切换到 helloflask 文件夹内之后，整个 1.1 小节你只需要执行下面这行命令：

$ pip install -r requirements.txt

而第二部分每章开头的下面这两行命令：

$ pipenv install --dev
$ pipenv shell

都要替换为：

$ pip install -r requirements.txt

这个命令会安装对应项目的所有依赖，所以后续介绍各个 Python 库时的安装命令不需要再执行。

方法二：使用 virtualenv/venv 来管理虚拟环境，搭配 pip 来管理依赖

第二种方法是改用更基础的工具：你仍然使用 pip 安装依赖，同时搭配 virtualenv 或 venv 来管理虚拟环境。如果你选择这个方法，那就跳过书中对 Pipenv 的介绍，改为阅读这篇《要不我们还是用回 virtualenv/venv 和 pip 吧》。阅读完上述文章后，再继续阅读。

现在你可以跳过 Pipenv 相关的内容。第一章切换进 helloflask 目录后，整个 1.1 小节你只需要执行下面的命令：

$ python -m venv env  # Linux、macOS 系统的 Python3 用户，使用 python3 -m venv env
$ env\Scripts\activate  # Linux、macOS 系统使用 source env/bin/activate
$ pip install -r requirements.txt  # 这个命令会安装对应项目的所有依赖

附注 ：上面命令里 # 号及之后的文字是注释，不需要输入。如果你使用 Python2，第一条命令需要改为 virtualenv env。这三行命令的作用依次为：创建虚拟环境、激活虚拟环境、从 requirements.txt 文件安装依赖列表。

类似的，第二部分每章开头的下面这两行命令：

$ pipenv install --dev
$ pipenv shell

都要替换为：

$ python -m venv env  # Linux、macOS 系统的 Python3 用户，使用 python3 -m venv env
$ env\Scripts\activate  # Linux、macOS 系统使用 source env/bin/activate
$ pip install -r requirements.txt  # 这个命令会安装对应项目的所有依赖

同时书中所有 pipenv install xxx 形式的命令都替换为 pip install xxx（不过你并不需要一个一个执行，因为每章开头执行 pip install -r requirements.txt 时会安装所有项目相关的依赖）。

对于 PyCharm 设置 Python 解释器部分的内容，大致可以沿用，只不过在图 1-4 的位置你需要从列表里选择当前目录 env 文件夹（虚拟环境文件夹）中的 Python 解释器，根据操作系统的不同，将会是 env/bin/python 或 env\Scripts\python.exe。

退出虚拟环境时，使用下面的命令：

$ deactivate

使用书中同样的代码，但是却出现报错？/ 我该怎么安装依赖？

有一些 Python 库在版本变化时会带来 API 的变化，而书中示例程序代码是基于每章开头注明的 Python 库来开发的，所以在更新依赖版本的时候可能会导致示例程序的代码出错。我建议你按照书中的命令来安装依赖，这会从项目依赖文件里安装固定版本的依赖列表，不要跳过第二部分每章开头的命令。

具体来说，如果使用 Pipenv，对应的安装依赖的命令是：

$ pipenv install --dev

如果使用 pip，对应的命令则是（如果创建了虚拟环境，需要先激活虚拟环境）：

$ pip install -r requirements.txt

如果是第一章的示例程序，那么在 helloflask 目录下执行一次即可。如果是第二章的四个程序，那么在每一个程序的根目录执行一次即可。后续所有介绍新的 Python 包时给出的安装命令不用再执行。

关于第一部分示例程序的项目结构和启动问题

在第一部分的源码中，一共有 6 个 Flask 程序，分别保存在 helloflask/demos/ 目录下的六个子文件夹内。用来存储环境变量的 .env 和 .flaskenv 文件需要在这些子文件夹内创建，而不是放到顶层目录（helloflask/）。同时为了方便操作，这 6 个程序共用同一个虚拟环境，所以在 helloflask/ 目录下创建虚拟环境。

注意 不要在 helloflask/ 目录下创建 .env 和 .flaskenv 文件，这会导致子目录下的程序无法正确启动（issue #3561）。

如果你按照书里给出的提示执行命令，一般不会出现问题。但是为了防止各种意外情况，这里列一下本书第一部分的操作流程（$ 符号前是当前工作目录）。

具体的操作顺序就是，克隆仓库以后，切换到 helloflask 目录：

$ cd helloflask

然后创建虚拟环境、激活虚拟环境、安装依赖：

/helloflask $ python -m venv env  # Linux、macOS 系统的 Python3 用户，使用 python3 -m venv env
/helloflask $ env\Scripts\activate  # Linux、macOS 系统使用 source env/bin/activate
/helloflask $ pip install -r requirements.txt  # 这个命令会安装对应项目的所有依赖

接着看到介绍 Flask 最小程序部分，启动第一部分的示例程序：

helloflask/ $ cd demos/hello
helloflask/demos/hello $ flask run

现在看到了第二章，启动第二部分的示例程序（先执行 cd .. 回到上层目录，即 demos/ 目录）：

helloflask/demos/hello $ cd ..
helloflask/demos $ cd http
helloflask/demos/http $ flask run

看到第三章，启动第三部分的示例程序：

helloflask/demos/http $ cd ..
helloflask/demos $ cd template
helloflask/demos/template $ flask run

以此类推。

遇到了自己没法解决的问题怎么办？

如果遇到问题，你可以先尝试：

  • 看一下本书 GitHub 仓库里的 FAQ 页面 有没有你要找的答案
  • 在搜索引擎搜索你的错误信息关键字，尝试自己解决

自己无法解决的话，可以：

  • 发到 GitHub（issue）和论坛（用文字形式贴出完整的错误信息、相关代码和命令，尽可能的详细描述相关信息）。
  • 发到交流群（建议优先选择发到 GitHub 和论坛，我会定期回复，群聊沟通效率很低，更适合闲聊）

要不我们还是用回 virtualenv/venv 和 pip 吧

9条回复

这篇文章没什么新东西，只是介绍古老又靠谱的 Python 虚拟环境和依赖管理方式：virtualenv/venv+pip。一来方便被我在《Flask 入门教程》和《Flask Web 开发实战》带入 Pipenv 坑的初学者了解基础工具的用法，二来方便其他 Python 初学者参考，自己顺便做个总结。如果你想了解更多详细内容，Python 官方教程这一章写的更好，可以替代这篇文章。

既然大部分试图简化 Python 虚拟环境和依赖管理工作流程的新工具都不够稳定，继续使用 virtualenv/venv 和 pip 这样的底层工具也是一个不错的选择，而且大多数人也是这么做的。它们虽然用起来有一点麻烦，但至少更可靠。

基本概念

下面是一些基本概念：

  • PyPA：指 Python Packaging Authority，一个维护 Python 打包相关项目的小组，相关项目具体见 https://github.com/pypa。
  • pip：Python 包安装器 。
  • virtualenv：Python 虚拟环境管理工具。
  • venv：Python 标准库内置的虚拟环境管理工具，Python 3.3 加入，Python 3.5 开始作为管理虚拟环境的推荐工具，用法类似 virtualenv。如果你使用 Python 3，推荐使用 venv 来替代 virtualenv。

使用 virtualenv/venv 管理虚拟环境

venv 模块

如果你使用 Python 3（具体说是 Python 3.3 及以上版本），推荐使用标准库内置的 venv 模块替代 virtualenv，两者的使用方式基本相同，唯一不同的是创建虚拟环境的方式。

如果你使用 Python 2，那就只能选择 virtualenv，你需要额外安装它。我先假设你已经安装了 pip，因为在 Python 2 >=2.7.9 或 Python 3 >=3.4 这些版本的 Python 会一并安装 pip，其他版本可以参考文档的安装部分。在 Windows 下使用下面的命令安装 virtualenv：

$ pip install virtualenv

其他操作系统可以使用下面的命令安装：

$ sudo pip install virtualenv

尽管不推荐使用 sudo pip 的方式安装 Python 包，但这仍然是最简单和统一的方式。更安全的方式是使用系统包管理器来安装，或是使用 pip –user 方式安装。

创建虚拟环境

假设我们的项目名叫 snow，创建对应的文件夹然后切换到根目录：

$ mkdir snow
$ cd snow

如果使用 venv，那么使用下面的命令创建虚拟环境，其中 snow-venv 是虚拟环境的名字，也作为创建的虚拟环境文件夹名称，你可以自由修改（通常会使用 venv 或 env 作为虚拟环境名）：

$ python -m venv snow-venv

如果使用 virtualenv，则使用下面的命令：

$ virtualenv snow-venv

这会在当前目录创建名为 snow-venv 的虚拟环境文件夹，你需要把这个文件夹名称加入 .gitignore 文件以便让 Git 忽略。

激活虚拟环境

通过执行对应的激活脚本来激活虚拟环境，不同操作系统的激活命令（激活脚本及路径）有一点不同。Windows（CMD.exe）使用下面的命令激活：

$ snow-venv\scripts\activate

Linux 和 macOS（bash/zsh）使用下面的命令：

$ source snow-venv/bin/activate

或：

$ . snow-venv/bin/activate

类似的，其他终端程序可以执行对应的激活脚本来激活虚拟环境。

激活虚拟环境以后，命令行提示符前会显示当前虚拟环境的名字：

(snow-venv) $

使用 deactivate 命令可以退出虚拟环境。

使用 pip 管理依赖

简单列一下基本用法，虽然大部分人都很熟悉了……以 Flask 为例，首先是安装依赖：

(snow-venv) $ pip install flask

更新依赖：

(snow-venv) $ pip install --upgrade flask

或是：

(snow-venv) $ pip install -U flask

卸载依赖：

(snow-venv) $ pip uninstall flask

除此之外，还有 pip show flask 命令可以查看某个依赖的详细信息，pip list 列出所有依赖。

下面的命令可以手动生成依赖列表：

(snow-venv) $ pip freeze > requirements.txt

如果你需要手动开发依赖和生产依赖，可以手动把开发相关的依赖放到单独的文件，比如 requirements-dev.txt。

当你需要在新的机器创建程序运行环境时，（创建虚拟环境后）只需要使用下面的命令从依赖文件安装所有依赖：

(snow-venv) $ pip install -r requirements.txt

如果安装包的时候速度太慢，可以考虑设置 PyPI 国内镜像，具体参考这篇文章。

从其他工具迁移回来

如果你想从 Pipenv 迁移回来，方法很简单，只需要生成一个 requirements.txt 文件即可。使用下面的命令生成一般依赖列表：

$ pipenv lock -r

使用下面的命令输出开发依赖列表：

$ pipenv lock -r --dev

然后手动把两个命令的输出保存为 requirements.txt 和 requirements-dev.txt。

从 Poetry、Conda 等其他工具迁移回来可以使用 pipreqs 来生成 requirements.txt，它会基于项目代码的导入语句来生成依赖列表。

在下一篇文章，我会介绍一些辅助工具来搭配 virtualenv/venv+pip 使用，让虚拟环境和依赖管理更方便，比如 virtualenvwrapper、pip-tools 等。

（4）

只用来管理 Python 版本和虚拟环境，Miniconda 也是一个很好的选择

2条回复

Anaconda 是一个面向数据科学的 Python 发行版，它打包了 Conda、Python 和一堆机器学习和人工智能相关和常用的包，而且还可以用来安装一些非 Python 编写的库。对于科学计算相关的用途非常方便，开箱即用。看起来很适合实验室或是学校机房使用……

对于常规的 Python 开发来说，Anaconda 太重了，而且主要面向科学计算领域，但是精简版的 Miniconda 却是一个很好的 Python 版本和虚拟环境管理工具。

更重要的是 Miniconda 兼容三个主流操作系统，而且不同平台使用同样的命令和接口（Conda 4.6 以上）。这大概算是个人偏好，因为我总在写东西给别人看，所以总是喜欢兼容主流操作系统并且接口统一的解决方案。而且另一方面 pyenv、virtualenvwrapper、direnv 等等相关替代工具都没有原生 Windows 支持。 

Miniconda 是什么

先来理清几个概念：

  • Conda：包、依赖和环境管理器。
  • Anaconda（某种蟒蛇的名字）：面向数据科学的 Python 发行版，包含 conda、conda-build、Python 和 100+ 常用的数据科学常用的库及其依赖。
  • Miniconda：精简版的 Anaconda，也是一个 Python 发行版，只包含 conda、Python 和一些基本的包。

相关资源：

Miniconda 基本用法

首先你需要访问下载页面下载对应操作系统的安装包进行安装，Python 版本选择你想作为默认选项（base version）的版本。然后打开 Windows 下的 Anaconda Prompt 或是 Anaconda Powershell Prompt，Linux 或 macOS 直接使用终端程序。

下面是一些关键用法介绍，详细内容可以阅读 Conda 文档。

创建虚拟环境

使用 conda create 命令创建虚拟环境，使用 –name 选项（-n）指定虚拟环境名称：

$ conda create --name foo

使用 conda info 命令查看当前环境名称、Python 版本、虚拟环境文件夹位置、Conda 版本等等各种信息：

$ conda info

使用 –envs 选项（-e）查看所有已创建的虚拟环境。在列出的虚拟环境中，使用星号（*）标识的是当前激活的虚拟环境：

$ conda info --envs

激活虚拟环境

使用 conda activate 命令激活虚拟环境，添加虚拟环境名作为参数：

$ conda activate foo

激活以后会在命令行提示器前显示虚拟环境名称，比如：

(foo) $

不添加虚拟环境名称，就会重新激活基础环境（base）：

$ conda activate

设置虚拟环境的 Python 版本

在创建虚拟环境的时候，可以使用 python 参数指定 Python 版本。假设你使用的 Miniconda 默认版本是 Python 3.7，如果你想创建一个 Python 2.7 的虚拟环境，使用下面的命令：

$ conda create --name snakes python=2.7

你可以在虚拟环境名加上标识方便识别 Python 版本，比如：

$ conda create --name snakes-py27 python=2.7

搭配 pip / Poetry 来管理依赖

因为 Conda 安装库的时候默认使用 Conda 自己的仓库，这里包含的 720 多个库除了流行的 Python 包外大多是数据科学相关的包。所以，更好的选择是使用官方 PyPI 仓库，这样可以确保你使用到最近更新的包，而且不会出现有些包找不到的情况。

我们要做的就是只用 Conda 的 Python 版本和虚拟环境管理功能，不用它来管理依赖。依赖管理（安装、卸载、更新等）仍然使用 pip 进行，或是进一步搭配 pip-tools 来管理依赖。

你需要在 conda 环境内使用下面的命令安装 pip：

$ conda install pip

或是统一使用下面的命令格式创建虚拟环境：

$ conda create --name bar pip

这样在执行 pip 命令时会使用虚拟环境内的 pip，而不是系统全局的 pip。这样做的副作用是会产生几个多余的依赖。

除此之外，你也可以搭配使用 Poetry。Poetry 默认会自动创建虚拟环境，所以需要关闭 Poetry 自动创建虚拟环境的设定，执行下面的命令即可：

$ poetry config settings.virtualenvs.create false

总结

按照我目前掌握到的信息，Miniconda 的优缺点总结如下：

优点

  • 用法简单，​易于上手
  • 替代 pyenv+virtualenv/venv+virtualenvwrapper 的多个工具组合
  • 类似 virtualenvwrapper，可以在任意位置激活虚拟环境，而不是必须在项目根目录
  • 支持管理不同的 Python 版本
  • 兼容性很好，支持 Windows

缺点

  • 在 Windows 下，需要使用专用的命令行程序
  • 依赖管理比较弱，需要搭配 pip/Poetry 来使用
  • conda 和 pip/Poetry 组合存在潜在的冲突，但情况在改善

既然一个 Miniconda 就能很好的胜任 Python 版本管理和虚拟环境管理的任务，为什么要用 pyenv+virtualenv/venv+virtualenvwrapper 呢？遗憾的就是依赖管理功能不够完善，和 pip/Poetry 搭配使用则可能会有潜在的冲突。所以，推荐觉得 virtualenv/venv+pip 搭配太麻烦的初学者使用；推荐能接受 Conda+pip/Poetry 这种搭配的人使用；推荐使用 Python 做数据科学相关工作的人使用。

对比之下，最稳定的解决方案大概还是 virtualenv/venv+pip+其他工具……
（如果你发现了错误描述、有不同看法和想要补充的信息，欢迎评论。）

（3）

相比 Pipenv，Poetry 是一个更好的选择

4条回复

前情提要

Pipenv 描绘了一个美梦，让我们以为 Python 也有了其他语言那样完善的包管理器，不过这一切却在后来者 Poetry 这里得到了更好的实现。

这几年 Pipenv 收获了很多用户，但是也暴露了很多问题。虽然 Lock 太慢、Windows 支持不好和 bug 太多的问题都已经改进了很多，但对我来说，仍然不能接受随时更新锁定依赖的设定，在上一篇文章《不要用 Pipenv》里也吐槽了很多相关的问题。

在这篇文章里，我会介绍一个看起来和事实上都更靠谱的 Python 虚拟环境和依赖管理工具 Poetry，作者是 Sébastien Eustace。这是一个新的坑吗？我想并不是，尽管这是一个更年轻的工具，1.0 还没有发布，也存在各种各样的 bug，但至少基本使用流程没有问题，用法设计也符合直觉。

Poetry 是什么

Poetry 和 Pipenv 类似，是一个 Python 虚拟环境和依赖管理工具，另外它还提供了包管理功能，比如打包和发布。你可以把它看做是 Pipenv 和 Flit 这些工具的超集。它可以让你用 Poetry 来同时管理 Python 库和 Python 程序。

安装 Poetry

官方推荐的安装命令是使用自带的 get-poetry.py 脚本，使用 curl：

$ curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python

或者直接下载这个安装脚本 get-poetry.py，然后在本地执行。

因为这个命令在安装时会从 GitHub 下载一个 7M 的压缩包，如果不用代理某些地区可能会很慢。实际测试使用代理安装耗时约 30 秒，不用代理等了 5 分钟，然后连接被重置。

如果没有用代理，可以用 pip 安装（不过 Poetry 官方文档不建议这么做，因为有可能会造成依赖冲突，可以考虑用 pipx 或 pipsi）：

$ pip install --user poetry

安装后可以使用下面的命令确认安装成功：

$ poetry --version
Poetry 0.12.17

如果报错，可以试试重新创建一个命令行会话。

附注 在 Mac 上安装报错 ~/.bash_profile 权限错误，临时没管，也能正常运行。后续可以考虑手动把 ~/.poetry/bin 加进去。

Poetry 的基本用法

Poetry 的用法很简单，大部分命令和 Pipenv 接近。我们需要先了解一些基本概念和 Tips：

  • 使用 PEP 518 引入的新标准 pyproject.toml 文件管理依赖列表和项目的各种 meta 信息，用来替代 Pipfile、requirements.txt、setup.py、setup.cfg、MANIFEST.in 等等各种配置文件。
  • 依赖分为两种，普通依赖（生产环境）和开发依赖。
  • 安装某个包，会在 pyproject.toml 文件中默认使用 upper bound（中文翻译？）版本限定，比如 Flask^1.1。这被叫做 Caret requirements（中文翻译？），比如某个依赖的版本限定是 ^2.9.0，当你执行 poetry update 的时候，它或许会更新到 2.14.0，但不会更新到 3.0.0；假如固定的版本是 ^0.1.11，它可能会更新到 0.1.19，但不会更新到 0.2.0。总之，在更新依赖的时候不会修改最左边非零的数字号版本（对于 SemVer 版本号而言），这样的默认设定可以确保你在更新依赖的时候不会更新到具有不兼容变动的版本。另外也支持更多依赖版本限定符号。
  • 不会像 Pipenv 那样随时更新你的锁定依赖版本，锁定依赖存储在 poetry.lock 文件里（这个文件会自动生成）。所以，记得把你的 poetry.lock 文件纳入版本控制。
  • 执行 poetry 或 poetry list 命令查看所有可用的命令。

如果你想了解更多进阶的内容，比如设置命令行补全、打包和发布等等，请阅读 Poetry 文档。

准备工作

如果你是在一个已有的项目里使用 Poetry，你只需要执行 poetry init 命令来创建一个 pyproject.toml 文件：

$ poetry init

根据它的提示输入你的项目信息，不确定的内容就按下 Enter 使用默认值，后续也可以手动更新。指定依赖的环节可以跳过，手动安装会更高效一点。

如果你想创建一个新的 Python 项目，使用 poetry new <文件夹名称> 命令可以创建一个项目模板：

$ poetry new foo

这会创建一个这样的项目结构：

foo
├── pyproject.toml
├── README.rst
├── foo
│   └── __init__.py
└── tests
    ├── __init__.py
    └── test_foo.py

如果你想使用 src 文件夹，可以添加 –src 选项，这会把程序包嵌套在 src 文件夹里。

创建虚拟环境

使用 poetry install 命令创建虚拟环境（确保当前目录有 pyproject.toml 文件）：

$ poetry install

这个命令会读取 pyproject.toml 中的所有依赖（包括开发依赖）并安装，如果不想安装开发依赖，可以附加 –no-dev 选项。如果项目根目录有 poetry.lock 文件，会安装这个文件中列出的锁定版本的依赖。如果执行 add/remove 命令的时候没有检测到虚拟环境，也会为当前目录自动创建虚拟环境。

激活虚拟环境

执行 poetry 开头的命令并不需要激活虚拟环境，因为它会自动检测到当前虚拟环境。如果你想快速在当前目录对应的虚拟环境中执行命令，可以使用 poetry run <你的命令> 命令，比如：

$ poetry run python app.py

如果你想显式的激活虚拟环境，使用 poetry shell 命令：

$ poetry shell

安装包

使用 poetry add 命令来安装一个包：

$ poetry add flask

添加 –dev 参数可以指定为开发依赖：

$ poetry add pytest --dev

追踪 & 更新包

使用 poetry show 命令可以查看所有安装的依赖（可以传递包名称作为参数查看具体某个包的信息）：

$ poetry show

添加 –tree 选项可以查看依赖关系：

$ poetry show --tree

添加 –outdated 可以查看可以更新的依赖：

$ poetry show --outdated

执行 poetry update 命令可以更新所有锁定版本的依赖：

$ poetry update

如果你想更新某个指定的依赖，传递包名作为参数：

$ poetry update foo

卸载包

使用 poetry remove <包名称> 卸载一个包：

$ poetry remove foo

常用配置

Poetry 的配置存储在单独的文件中，比 Pipenv 设置环境变量的方式要方便一点。配置通过 poetry config 命令设置，比如下面的命令可以写入 PyPI 的账号密码信息：

$ poetry config http-basic.pypi username password

下面的命令设置在项目内创建虚拟环境文件夹：

$ poetry config settings.virtualenvs.in-project true

另一个常用的配置是设置 PyPI 镜像源，以使用豆瓣提供的 PyPI 镜像源为例，你需要在 pyproject.toml 文件里加入这部分内容：

[[tool.poetry.source]]
name = "douban"
url = "https://pypi.doubanio.com/simple/"

不过经过测试 Poetry 会使用 pip.ini 设置的 PyPI 镜像，而且豆瓣的源好像很久没更新了（创建虚拟环境安装的默认依赖里 importlib-metadata==0.20 找不到），这篇文章列出了一些其他国内的 PyPI 源。

总结

总的来说，我愿意深入尝试和使用 Poetry。当然，经过使用 Pipenv 的痛苦经历，我对推荐工具这种事情变得更保守了。所以我不推荐 Python 初学者使用，不推荐直接在生产环境使用，不推荐没法正常访问国际互联网的人使用。

列一些我了解到的优缺点：

优点

  • 使用标准的 pyproject.toml 标准，不用写多个配置文件
  • 同时支持管理 Python 程序和 Python 库
  • 更符合直觉的默认设计，比如不会随便更新锁定版本的依赖
  • 干净简洁的命令行输出，没有星星和蛋糕
  • 安装包的时候，使用 upper bound 版本限定，而不是 Pipenv 默认的通配符
  • 卸载包的时候，直接卸载孤立的子依赖，不需要像 Pipenv 那样需要再执行 pipenv clean

缺点

  • 「poetry」这个单词有一点难打……
  • 引入新的 pyproject.toml 标准，旧项目需要一点迁移成本和学习成本
  • 会有一些潜在的 bug
  • 解析依赖的过程有时候会久一点
  • 对虚拟环境的管理控制有些弱，没有 Pipenv 那样的删除虚拟环境和清空依赖的操作
  • 缺少一个稳定的维护团队，有大量 issue 和 PR 等待处理，但情况在逐渐好转

当然，你还是可以选择继续使用 virtualenv 和 pip 这些基础工具，直到有一个完美的解决方案出现。或者，也可以选择试试新东西，然后尝试改进它，让完美的解决方案早一点出现。

（2）

回应《也谈「不要用 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 的介绍里宣传这是「官方推荐」，而注明的官方来源则是「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 python.org」：

blank

和在 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 对标的是 requirements.in，Pipfile.lock 对标的是 requirements.txt：

blank

blank
按照大部分人的理解，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

不要用 Pipenv

2条回复

注意：本文写于 2019 年 8 月，其中描述的内容在新版本的 Pipenv 中或已得到修复或改进，请谨慎参考。

如果你是《Flask Web 开发实战》的读者，请访问《Flask Web 开发实战》虚拟环境/依赖/Pipenv 等问题解决方法。

Pipenv 让我用的很痛苦，有一种被欺骗的感觉，而且很后悔在《Flask Web 开发实战》里采用它。

大部分情况下，它很好用，但却存在太多问题，有一些问题让人简直没法接受。我知道有人会说「这是开源程序，有 bug 就自己去修」、「爱用不用，没人强迫你」，但问题是，一个进行大肆推广，甚至借 PyPA 做背书来宣传（经常让人误以为是 Python 官方推荐）的工具却连基本的使用流程都没做好，这不是合理和正常的行为。 引用这个 HN 评论的话说就是：

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

在这篇（劝退）文章里，我会分别从包的安装、更新、卸载来测试并指出 Pipenv 的一些问题。

测试准备

  • 项目：Bluelog（一个 Flask 博客）
  • Pipenv 版本：2018.11.26（最新版本）
  • 操作系统：Windows 10，Cmder
  • 测试流程：每一次测试命令前都会删除已经创建的虚拟环境（pipenv –rm），重置 Pipfile 和 Pipfile.lock 文件变动，然后重新创建虚拟环境（pipenv install）。

安装包

假设想给这个旧项目 Bluelog 添加新功能，拿到旧项目的代码，打算安装一个 Flask-Avatars 包。查了文档，发现安装包要使用 pipenv install 命令，所以执行了下面的命令：

$ pipenv install flask-avatars

结果发现其他所有的不相干依赖都被更新了……

WTF，这不是反人类吗（说好的「Python Development Workflow for Humans.」呢）？我安装一个包，默认行为竟然是更新其他所有不相干且已经锁定版本的依赖！

翻了文档才发现，要加一个 –keep-outdated 选项才能避免更新其他锁定的依赖：

$ pipenv install --help
...
--keep-outdated Keep out-dated dependencies from being updated in
Pipfile.lock. [env var: PIPENV_KEEP_OUTDATED]

好吧，那先忍着，多打一个命令行选项就是了：

$ pipenv install --keep-outdated flask-avatars

WTF，为什么所有依赖还是被更新了？

好吧，有 bug 很正常，我来提个 issue 吧，哎，好像有很多 issue 了？

重点评论：

Kenneth Reitz 先是说 lockfile 只要是过期了就总是会被重新生成（这是什么逻辑？），接着又说用 pipenv update depname，但其他人都回复不起作用（我下面会进行单独测试）。

接着，看到其他评论提到用 –selective-upgrade 选项：

$ pipenv install --help
...
--selective-upgrade Update specified packages.

我又继续使用 –selective-upgrade 选项：

$ pipenv install --selective-upgrade flask-avatars

仍然会更新所有依赖……

对了，顺便还测试了这个命令，依然没用：

$ pipenv install --keep-outdated --selective-upgrade flask-avatars

除了安装某个包会导致所有依赖版本被更新，Pipenv 在解决依赖的冲突上面也有一些不足，比如执行下面的安装命令（具体见 Poetry README）：

$ pipenv install oslo.utils==1.4.0

会提示无法安装成功：

ERROR: ERROR: Could not find a version that matches pbr!=0.7,!=2.1.0,<1.0,>=0.6,>=2.0.0

更新包

假设我想更新 Bluelog 这个项目用的 Flask 版本（从 1.0.2 更新到最新的 1.1.1）。查了文档，找到了 update 命令（https://docs.pipenv.org/en/latest/basics/#example-pipenv-upgrade-workflow），于是我执行下面的命令：

$ pipenv update flask
Locking [dev-packages] dependencies…
Success!
Locking [packages] dependencies…
Success!
Updated Pipfile.lock (fd55e3)!
Installing dependencies from Pipfile.lock (fd55e3)…
================================ 26/26 - 00:00:12
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
All dependencies are now up-to-date!

突然看到最后一行赫然写着「All dependencies are now up-to-date!」，我以为是搞错了，赶紧看了下 Pipfile.lock，WTF，为什么我所有的依赖（包括和 Flask 完全不相关的）又都被更新了？
依然，已经有很多相关 issue：

重点评论：

如果这个 issue 没有被锁定，这一句「I have no idea.」下面的图标不知道还会被点多少次。我猜 Kenneth Reitz 对这个 issue 让多少人头疼也没有 idea。

继续搜索，查文档，发现 update 命令也有 –keep-outdated 和 –selective-upgrade 两个选项：

$ pipenv update --help 
... 
--selective-upgrade Update specified packages.
--keep-outdated Keep out-dated dependencies from being updated in
Pipfile.lock. [env var: PIPENV_KEEP_OUTDATED]

先来试下 –keep-outdated：

$ pipenv update --keep-outdated flask

no luck，还是更新了所有依赖。继续试一下 –selective-upgrade：

$ pipenv update --selective-upgrade flask

依然没用，仍然会更新所有依赖……

继续查 issue，发现下面这些：

在 #3461 里发现了下面这个评论：

（因为 Frost Ming 是国内的同学，也是核心维护者，说明一下，这里无意冒犯，引用这个评论只是想说明 Pipenv 现在的开发状态。）

这段评论的重点是「In fact, the package name passed as argument is not used at all.」。

也就是说，pipenv update 实际上是不接受包名称参数的。这在下面这个评论也得到了印证：

Here is the important caveat:pipenv updatealwaystargets every package in your lockfile, without exception. It does not accept arguments.

一个还没实现的功能就写到文档里了？这真的不是开玩笑吗？不仅是写到了文档里，还写到了命令行帮助文档里：

$ pipenv update --help
Usage: pipenv update [OPTIONS] [PACKAGES]...

类似下面的场景：

  • 用户：怎么运行程序呢？好，查下文档，文档里说「执行 run 命令就可以运行程序」。哎？怎么没用？
  • 开发者：哦，这个功能还没实现，先写出来让你练练手。

最终的结果就是，如果你想更新一个包，那就只能手动把更新版本的包版本和 hash 编辑到 Pipfile.lock 里。这么做实在是太蠢了。

卸载包

假设我决定不再使用 Gunicorn，需要卸载它，在文档里查到 pipenv uninstall 命令（https://docs.pipenv.org/en/latest/basics/#pipenv-uninstall），于是执行下面的命令：

$ pipenv uninstall gunicorn

结果呢？为什么我所有的依赖又都被更新了！？好，我已经习惯了。看命令行帮助文档，同样有 –keep-outdated 命令：

$ pipenv uninstall --help
...
--keep-outdated Keep out-dated dependencies from being updated in
Pipfile.lock. [env var: PIPENV_KEEP_OUTDATED]

再试一下，虽然我已经不抱期待了：

$ pipenv uninstall --keep-outdated gunicorn

顺便说一句，卸载的另一个问题是，当你卸载一个包的时候，只会卸载这个包本身，而这个包引入的相关依赖都会被保留，需要手动使用 clean 或 sync 命令修正（参考 Poetry README）。

不要使用 Pipenv（至少是现在）

当然，Pipenv 一直在改进。比如 Windows 支持，Lock 很慢的问题，都有过很多的优化（暂且不提没优化之前的痛苦经历）。

但是，种种证据都在表明，这其实是一个半成品。承诺了很多，兑现的却很少。或许过一段时间等它真正成熟了，能够保证基本使用流程，并且可以修改哪些反人类的设定以后再考虑用它（我怀疑这一条是否能实现，除非完全「去 Kenneth Reitz 化」，并且有一个核心维护者能够来推动执行）。

现在，请不要使用它。

我很抱歉在《Flask Web 开发实战》以及文章《Pipenv：新一代Python项目环境与依赖管理工具》中，推动更多人用它，给大家带来潜在的麻烦。我计划了一些补救措施，会逐一执行：

  • 写这篇文章【DONE】
  • 给《Flask Web 开发实战》的五个实例项目追加 requirements.txt 文件，并在 README 中添加说明。
  • 如果《Flask Web 开发实战》能出第二版，修改所有 Python 包安装命令，去掉所有 Pipenv 相关介绍。
  • 写文章介绍替代的几种工具和用法，包括原有的 virtualenv+pip、virtualenvwrapper、Poetry 等。
  • 在 PyCon China 2019 的闪电演讲《Python 虚拟环境和依赖管理工具大乱斗》里提及这个信息。
  • 以后写推荐文章时对这种带着强烈个人风格的项目保持警惕，并对 Kenneth Reitz 这个名字相关的东西保持警惕。

你可以选择用回 virtualenv+pip（+virtualenvwrapper），或是尝试新工具，我会在下一篇文章介绍主要替代品 Poetry 的基本用法。

相关文章

（1）

蛇蛋：Python 中隐藏的彩蛋和笑话列表

发表回复

这是一个 Python 中隐藏的彩蛋和笑话列表。如果你还知道其他有趣的彩蛋和笑话，欢迎在 GitHub 上创建 PR 添加。

项目地址：https://github.com/greyli/shedan

Python 比你想象中的更有趣。

blank

A little girl goes into a pet shop and asks for a wabbit. The shop keeper looks down at her, smiles and says:

“Would you like a lovely fluffy little white rabbit, or a cutesy wootesly little brown rabbit?”

“Actually”, says the little girl, “I don’t think my python would notice.”

—Nick Leaton, Wed, 04 Dec 1996, Python Humor

1. Hello World

>>> import __hello__
Hello World!

Note：在 Python 中打印「Hello, World!」最简单的方式。

2. Python 之禅

>>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Note：Python 设计哲学 & Python 代码风格指南。

3. 《Python 之禅》丢失的一行

《Python 之禅》在 PEP 20 中引入，它本应该是 20 条格言，但是最终只写了 19 条。

Note：也许只是为了说明在文件的结尾总是应该保留一个空行。

4. 一堂简单的人生课

>>> import this
...
>>> love = this
>>> this is love
True
>>> love is True
False
>>> love is False
False
>>> love is not True or False
True
>>> love is not True or False; love is love  # FML
True

Note：不是彩蛋，只是一个解释器里的玩笑。

5. 反重力漫画

>>> import antigravity

Note：这会打开这个 xkcd 漫画，漫画展示了 Python 有多么简单易学。

6. 这不是一个选择，它定义了我们是谁

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Note：这用来快速结束任何关于在 Python 中引入大括号的讨论——不可能！

7. 起源

「Python」这个名字和蛇的种类没有关系。

Note：实际的来源是 Guido van Rossum 喜欢的电视剧《Monty Python’s Flying Circus》。

8. 反差

下面是打印出《Python 之禅》的 this.py 模块的内容：

s = """Gur Mra bs Clguba, ol Gvz Crgref

Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)

print("".join([d.get(c, c) for c in s]))

生成《Python 之禅》的代码本身违背了自己宣扬的风格建议。它丑陋而不美丽，隐式而不直观。

Note：使用了一种叫 ROT13 的置换加密法。

9. 有没有 C/C++ 用户？

再次引用《Python 之禅》：

There should be one-- and preferably only one --obvious way to do it.

Note：在很多语言里常常有两种方法做同一件事，即 --no 和 no--。这一行包含了一个隐藏的示例。

10. 命名标识符可以非常酷

>>> from math import pi
>>> π = pi
>>> area = π * r**2

>>> résumé = 'knows Python'
>>> 'Python' in résumé
True

>>> 我的英文名 = 'Grey Li'
>>> 我的英文名
'Grey Li'

>>> import webbrowser
>>> 我的网站 = 'http://greyli.com'
>>> webbrowser.open(我的网站)

Note：Python 3 中支持使用 Unicode 字符作为变量名。尽管如此，使用非英文字符作为变量名可能不是一个好主意，不过它确实会让处理科学公式的工作变得更有意思。

11. 选一个见面地点

>>> from antigravity import geohash
>>> # Your location, a date and that date's (or most recent) DJIA opening.
>>> # 你的位置，一个日期和这个日期（或最近）对应的道琼斯工业指数。
>>> geohash(37.421542, -122.085589, b'2005-05-26-10458.68')
37.857713 -122.544543

这可以用来生成一个 GPS 定位，在基于你所在位置的一个 1 经度长和 1 纬度宽的区域里。

Note：这个函数的源码在 这里，工作原理解释可以在这个 xkcd 漫画看到，也许这就是为什么这个函数也放到了 antigravity 模块里。

12. The FLUFL – Friendly Language Uncle For Life from PEP 401 — BDFL Retirement

>>> from __future__ import barry_as_FLUFL
>>> 1 <> 2
True
>>> 1 != 2
  File "<stdin>", line 1
    1 != 2
       ^
SyntaxError: invalid syntax

在认识到 Python 3.0 的不等运算符（!=）非常糟糕，是手指疼痛导致的错误后，FLUFL（指 Uncle Barry）重新恢复钻石型操作符（<>）作为唯一的不等运算符拼写。

Note：PEP 401 是一个愚人节玩笑（从编号可以看出来）。这个 PEP 声明 Guido van Rossum 要退休了。他会获得一个新的头衔，叫做「BDEVIL」（Benevolent Dictator Emeritus Vacationing Indefinitely from the Language，去度无限期语言假期的仁慈退休独裁者），接任者将会是 Barry Warsaw（即 Uncle Barry），Uncle Barry 的官方头衔是「FLUFL」（Friendly Language Uncle For Life，终生友好语言叔叔）。

13. InPynite?

>>> infinity = float('infinity')
>>> hash(infinity)
314159
>>> hash(float('-inf'))
-314159

一个散列值是一个固定尺寸的整型，它会标识一个特定的值。仔细观察，你会发现散列值的无限大是 10^5 x π。有意思的是，在 Python3 中，hash(float('-inf')) 将会生成 -10^5 x π，而在 Python 2 中则是 -271828（即 10^5 x e）。

Note：来源。

14. types.CodeType – Not for the faint of heart

如果你开始钻进 Python 的内部，你会在 help 输出看到一个关于 types.CodeType 的警告：不适合心脏脆弱者。

>>> import types
>>> help(types.CodeType)
...
Help on class code in module builtins:                                                    
                                                                                          
class code(object)                                                                        
 |  code(argcount, kwonlyargcount, nlocals, stacksize, flags, codestring,                 
 |        constants, names, varnames, filename, name, firstlineno,                        
 |        lnotab[, freevars[, cellvars]])                                                 
 |                                                                                        
 |  Create a code object.  Not for the faint of heart.                                    
 |                                                                                        
 |  Methods defined here:                                                                 
 |                                                                                                                                       
 ...

翻译自 https://github.com/OrkoHunter/python-easter-eggs 项目，原项目没有许可协议，已通过邮件申请获得翻译和发布许可。