有关poetry二三事

type

status

date

slug

summary

Poetry

Python packaging and dependency management made easy

poetry是一个python包管理工具，它集成了开发，构建，发布包的多项过程。清晰且现代化地辅助python开发工作。

快速上手

安装

我们可以使用pip安装poetry，在poetry安装之后，导入包与解析依赖的工作就可以交由poetry全权负责了，pip可以就此宣布退休。

将poetry安装在全局环境是一种合适的选择，这样使用起来就和其他包管理器很相似了，由位于全局的poetry管理其创建的一个个隔离的虚拟环境。注意千万不要将poetry安装在自身要管理的环境中，这样可能导致peotry自身的依赖发生不可控的变动。

It should in no case be installed in the environment of the project that is to be managed by Poetry. This ensures that Poetry’s own dependencies will not be accidentally upgraded or uninstalled.

配置

我们可以对poetry进行一些基本的配置：

我们可以修改一些想修改的项，比如缓存位置，虚拟环境默认位置等。如果你希望虚拟环境包文件的位置放置在项目目录下.venv文件夹中，也就是类似venv包管理器的行为，可以这样配置：

十分推荐这样做，poetry在项目目录下创建的.venv虚拟环境可以被vscode等开发工具很好地自动识别。

基本功能

创建新项目：

这个命令会生成一个基本的python包项目模板目录结构：

初始化一个已有的项目：

为一个已经存在的项目生成pyproject.toml等配置文件时使用：

安装一个项目：

这是以可编辑模式安装的，类似pip install -e这种功能，比如别人发布了一个使用poetry管理的项目，你要对这个项目进行二次开发，就可以使用这个安装命令：

导入新的包：

类似pip install和conda install不用多解释了吧：

更新包：

更新指定的包或更新所有锁定版本的依赖：

移除包：

这个也不用多解释了：

显示包信息：

类似pip list和conda list，显示环境下包的信息，也可以显示某个包的依赖信息：

显式地启动或关闭环境：

类似conda和venv中的activate，启动poetry环境：

一般是不需要的，直接使用poetry run，poetry也会自动检测目录下的虚拟环境。此外，开发工具会自动识别虚拟环境并为你在shell中引入：

进阶使用

配置文件：pyproject.toml

为依赖分组

我们可以为依赖创建分组，比如分离开发环境和生产环境，比如将用于测试，演示效果的包移动至开发环境中：

我们可以选择单独安装生产环境或者安装全部环境：

自定义poetry环境下脚本

创建脚本，我们可以在这里整合一些复杂的启动命令，或者运行测试用例等等：

运行脚本：

包管理&仅作为虚拟环境

如果不想用poetry作为包发布管理器，只想把它当作虚拟环境管理工具，可以在配置文件中指定：

如果不指定这一点，开发的项目会被视为包，则项目相关目录需要和name同名。

当然，有的时候你的项目比较复杂，不符合poetry能识别的包结构，你也可以显式指定一些目录作为包含的包，比如这样：

打包与发布

使用poetry发布包非常简单，以发布到PyPI源为例：

构建项目，运行以下命令后poetry会为你生成sdist和wheel文件夹，并且将poetry项目中的一些证书信息囊括进来：

接着要注册一个PyPI账号，在account settings页面找到图中设置，然后创建apikey：

在poetry中进行配置，填入你账号上创建的token：

然后就可以发布了：

特性与优势

详情见文末参考文章列表的第一篇，说的很全，我列一些我自己体验到的点在下面，主要还是和conda做对比：

相比conda这样的工具，poetry要轻量级许多，当不需要系统层面的隔离，或是为非python包的其他工具创建虚拟环境时，选用poetry是十分合适的。poetry只安装最小依赖，而不会安装完整软件包和系统级依赖，这让poetry安装的依赖数量更少，速度更快。

poetry能方便地访问PyPI源，并且和pip一样为所有包维护了统一的安装格式，终于不用为conda和pip混用而烦恼了。一些包只传了PyPI源而没有上传conda-forge，而对于另一些包如torch，tensorflow则是两个源有一定差别，总而言之pip和conda的混用会让整个工程难以重现，维护困难，而poetry则无需担心。

poetry删除包时，会删除所有的不被其他包使用的依赖，也就是类似pacman -Rns pkgname的逻辑，可谓安装地干净，移除也同样干净。而其他包管理器不一定有这样的逻辑，比如pip就不会移除包的依赖项，长期以来会导致无用依赖积压。

poetry项目的环境由pyproject.toml和poetry.lock维护，在迁移和他人二次开发时基本无痛。poetry能更加自动化，更加严格地更新环境文件，保证安装项是符合开发者指定的，不含冲突的依赖。而使用requirements.txt和requirements.yaml则常常令人血压上升，若指定版本则不够灵活且耗神费力，不指定版本，则未来依赖更新时容易产生冲突。

poetry对依赖冲突的分析和解决是清晰且严格的，假如你安装的包和之前的包产生了依赖冲突，poetry会列出依赖版本区间的具体信息，并且马上取消安装操作。你需要手动解决这个冲突，比如放宽某些安装的包的依赖版本区间，这比常常花大量时间试图解决冲突，最后还是大概率抛出错误给使用者的conda更加合理。

其他工具

最后再综合谈谈我接触过的其他包管理器。

标准库中的venv，python自带的虚拟环境，没有发布包的功能，使用机器上固定的python解释器创建虚拟环境，对于一些简单项目，学习任务等完全能胜任，适合不想额外折腾的初学者。

基于venv，viltualenv是它的加强版，能够为虚拟环境指定单独的python解释器，简单的项目也可以选用。

conda，虽然就我个人体验而言，poetry把我从conda的折磨中解救了出来，但是conda也确实拥有一些独特优势。conda能提供系统级别的依赖隔离，这一点在多人共用同一个服务器的时候很重要，conda能很好地将非python项隔离，譬如opencv涉及的C++相关依赖。conda甚至能为不同环境提供不同CUDA，gcc版本，这下新老项目在同一个服务器上也能和睦相处。

pixi是基于conda生态的产品，依赖维护文件要比conda更优秀，而且支持从PyPI和conda-forge两个源导入包（支持显式指定），用起来还不错，是替换conda的一个选择。

PDM是近来社区中评价比较好的一款包管理工具，由国人开发，基于PEP582即”本地包目录“而不是虚拟环境，灵活高效。亮点是能较好地支持conda-forge和PyPI源，和poetry一样有丰富的命令行工具和自定义配置。已加入未来主力包管理工具愿望单。

uv，略有听闻，目前解析依赖的速度时最快的，uv希望提供一个类似rust cargo的体验，也是目前广受好评的一款包管理器。