共计 2539 个字符，预计需要花费 7 分钟才能阅读完成。
一、起因
最近在逛一些当下比拟热的 python 开源代码（fastapi、langchain、redash）的时候，发现我的项目根目录都很难见到 requirments.txt 这个包依赖文件了，取而代之的是 pyproject.toml 文件和 poetry.lock 文件。而我，还只会应用 requirments.txt，来自程序员的直觉是，我曾经掉队了，不由得一阵危机感，随之而来的是几个问题：
- pyproject.toml 和 poetry.lock 这两个文件到底是啥？
- 为啥一线的开源我的项目都曾经弃用 requirments.txt？
- pyproject.toml 和 poetry.lock 好在哪？
去 python 官网逛了一下，发现了 PEP518 标准，是这么说的：
The build system dependencies will be stored in a file named pyproject.toml that is written in the TOML format
pyproject.toml 是 python 官网举荐的新标准，用于形容 python 我的项目的依赖，取代了之前的 requirments.txt，一个 pyproject.toml 文件大抵长这样
- 蕴含了代码库名称、版本、lisence 等 meta 信息，还有 python 版本、依赖包的版本等信息，比原来干瘪瘪的 requirments.txt 是要丰盛不少
poetry.lock 则是用于治理 python 我的项目依赖关系的工具 Poetry 生成的文件。它记录了我的项目所依赖的包的版本信息，帮忙开发者在不同的开发环境中放弃依赖的一致性，一个 poetry.lock 文件大抵长这样
- 形容了依赖包的版本、环境，以及依赖包的子依赖包的版本，甚至准确到了哈希值
那么这个 Poetry 是何方神圣，竟然受到泛滥一线开源我的项目的青眼，应该不是花瓶，探一探到底先。
于是照着 Poetry 官网文档操作了一波之后，不禁感叹：这才是正经的包治理！
二、Poetry VS 传统包治理
1、主动生成、治理可能残缺形容我的项目依赖的 toml 文件
传统包治理
- 以往常常会遇到一类状况，拿到一个我的项目，依据 requirements.txt 装置依赖的时候，因为 requirements.txt 不足对 python 版本的形容，导致接手的人不晓得 python 版本
- 之前有个我的项目是基于 python3.8 开发的，我选了过后还算比拟新的 python3.6，装置 requirements.txt，而后运行报错，排查之后才发现是 python 版本不统一导致的问题
Poetry
- 能解决以上问题，它会主动生成并治理 pyproject.toml 文件，生成代码库名称、版本、lisence 等 meta 信息，还有 python 版本、依赖包的版本等信息
2、为生产和开发环境提供独自的依赖
传统包治理
- 一个场景是，开发、测试环境须要的包，生产环境不肯定须要，比方 pytest、flake8、black、pycodestyle 等等，传统的做法是，建设多个 requirements.txt，比方：requirements-dev.txt、requirements-test.txt、requirements-pro.txt，这样文件繁多，不利于对立治理
Poetry
- 能够把所有环境的依赖比拟好地区分，都放入 pyproject.toml 文件中对立治理
3、更新包版本，主动在 pyproject.toml 中同步更新
传统包治理
- 传统工具 pip 或者 conda 在更新或者增加包之后，须要手动或者 pip freeze 一下依赖，频繁更新容易遗记
Poetry
- 将这个过程合二为一，只须要 poetry add XXX，依赖信息会自动更新到 pyproject.toml
4、依赖关系的解决
传统包治理
- 应用 pip 治理依赖比拟大的一个痛点场景是，装置 pandas==2.0.2，须要依赖 numpy>=1.20.3，而后，你又装置了 numpy==1.20.2，只管产生了依赖抵触，pip 仍然会将 numpy 版本更新到 1.20.2（与 pandas==2.0.2 对于 numpy 版本的要求抵触），这样，默默地引入依赖抵触的包，会在后续的程序运行中导致潜在的抵触问题，而且不太好排查解决。
Poetry
- 会立刻报错，并提醒正当的版本区间
5、彻底删除已有依赖包以及子依赖包
传统包治理
- 应用 pip 治理依赖另一个比拟大的痛点场景是，比方装置 pandas==2.0.2 的时候，顺带装置了包含 numpy>=1.20.3 在内的数十个子依赖，当你想要卸载 pandas 的时候，pip uninstall pandas，只会卸载 pandas 自身，而不会去卸载其下的数十个子依赖包，导致的问题就是，呈现大量不会应用到的【孤儿】子依赖包，长此以往，包占用的空间【虚胖】，节约存储空间，包治理也一团糟。
Poetry
- 能够很好地治理依赖以及子依赖，删除依赖包的同时，一并删除子依赖，保护一个洁净高效的我的项目环境。
三、总结
Poetry 提供了比 pip 和 conda 更多的劣势
- 统一的软件包装置：Poetry 提供了一个统一的格局来装置任何软件包，确保整个我的项目有一个标准化的办法。
- 高效的依赖性治理：Poetry 只为指定的软件包装置必要的依赖性，缩小你环境中不相干的软件包的数量。
- 简化的软件包移除：Poetry 简化了软件包及其相干依赖关系的移除，使其易于保护一个洁净和高效的我的项目环境。
- 依赖性解决：Poetry 的确定性解析器无效地解决了依赖关系，及时辨认并解决任何不统一或抵触。
尽管 Poetry 可能须要团队成员破费一些额定的工夫和精力来学习和适应，但从久远来看，应用 Poetry 这样的工具能够为你节省时间和精力。
给所有 python 开发安利这款神器。
四、号外
- 看看隔壁，java（gradle.build）、前端开发（package.json），早都曾经用上了现代化的包管理工具及标准，不得不感叹，python 在机器学习、深度学习上的确拿捏了，但在工程化这方面，还是落后于他人家的小孩不止一点半点，工程化比拟拉胯的另一个例子是，python 直到最近一两年，随着 fastapi 的推广，才大范畴用上 swagger，极大地促成了接口开发联调效率，用过之后，不得不说，真香。
