本文已参与「新人创作礼」活动，一起开启掘金创作之路。
现在比较流行的Python虚拟环境管理工具，主要是：
-
poetry github.com/python-poet…
-
pipenv github.com/pypa/pipenv
-
conda github.com/conda/conda
其中，我最喜欢用的是poetry，原因是有些人走着走着就散了。。。
17年刚开始做Python后端开发时，pipenv刚被requests库的作者kz创建出来没多久，就火爆Python界，我试了一下，虽然还有瑕疵，但确实比virtualenv省心，不用担心忘记更新requirements.txt的问题，而且自动加载.env文件这点尤其另我欣喜。于是，我极力鼓吹，加写了个PPT做技术分享之后，公司的所有后端项目，都使用了pipenv来管理虚拟环境，连服务器的部署也是用它来创建虚拟环境和安装依赖包的。
燃鹅，不过一开始多么充满热情，生活总会悄然的在你意想不到的地方，发生一些改变，于是你会发现，终究是错付了。。。
后来，或许是kz在py界的良好信誉力，pipenv成为了pip所在项目pypa的官方推荐包管理工具，使用pipenv更加的广为人知，各种issue和讨论的铺天盖地。pipenv也由kz的个人仓，转移的pypa的组织仓。再后来，kz把pipenv的merge和管理权限移交给其他人，他自己跳槽到数字海洋去写go代码去了。。。
最终，两年后，在一次因为使用pipenv导致的生产事故之后，我说服了公司的CTO，把pipenv全线更换成了poetry，原因有如下几点：
-
搜索如何解决pipenv导致的问题时，发现竟然也有人吐槽它的各种违反人类直觉的设计，更有趣的是这个人还造了一个叫poetry的轮子来解决这些问题，而且这个轮子的star数量很挺多。进一步了解时，发现Python开发的前辈还写过文章来推荐它。于是这个极具浪漫主义色彩的库，给我留下了良好的第一印象~
-
不记得从哪一年开始的了，Python官方为了解决各种配置文件导致代码库零乱的问题，推出了pyproject.toml来一统江湖。原本我的代码库里，可能有tox.ini, pytest.ini, setup.cfg, setup.py, Makefile, MANIFEST.in, .coveragerc, .isort.cfg等众多配置文件。现在可以统统塞进pyproject.toml里面了，对于不负责项目骨架搭建的同学，就不用再一个个去研究那些配置文件有什么用、能不能删等问题，只需专注业务层就好了。然后今天的主角
poetry，它一开始就设计成，把依赖包放在pyproject.toml里，不像pipenv还要有Pipfile来单独记录依赖和版本。虽然poetry也有这样那样的缺点，但把依赖包放在pyproject.toml里，这一点就像太阳一出来，星星就不见了一样，深深地左右着我的决定。
Show me the code
- 使用poetry新起一个项目：
poetry new my-project
cd my-project
poetry shell
- 在已有项目里，使用初始化poetry
cd previous-project
poetry init # 一路回车即可
poetry shell
