Python后端项目之：我为什么使用pdm+uv

在试用了一段时间的uv和pdm之后，上个月(2025.06)开始，逐步把用了几年的poetry替换成了pdm+uv（pipx install pdm uv && pdm config use_uv true)

为什么poetry -> pdm:

通过ssh连接到服务器并使用poetry shell激活虚拟环境之后，如果没有主动退出，那么该进程有可能一直在跑着，即使你已经断开了服务连接，有时候这个进程甚至会占用100%的CPU
poetry需要额外安装poetry-plugin-version插件才能支持dynamic version，而pdm自身就支持
poetry需要加插件才能支持换国内的镜像源，而pdm直接用自带的config命令就行
poetry居然没有官方的github action构件，写ci时还得手动pip install poetry
poetry最大的痛点是lock贼慢，依赖比较多的项目，到最后懒得更新lock文件了，直接手动更新pyproject.toml并通过pip来安装和升级依赖

为什么时pdm+uv，而不是只用uv：

在国外一般使用清华阿里等pypi镜像源，uv的lock文件里会携带源信息，这就导致即使服务器环境和本地环境执行uv lock会产生不同的结果
uv的优势是快，但pdm在启动use_uv之后，速度已经相差不大
pdm在工程化支持这一块做的相对较好，例如pdm new my-project可以直接创建新项目，而uv目前(uv 0.7.20)并不支持，再者pdm是python开发的，写插件很方便，如：pdm self add pdm-plugin-i

结论：江山代有人才出，长江后浪推前浪。用了好几年的poetry，虽然各种槽点，但确实比pip+requirements.txt好一些。node前端的包管理工具，除了npm就是yarn和pnpm，而Python后端却是conda、pipenv、poetry、flit、hatch、uv、pdm、setuptools-scm、Rye让人眼花缭乱。其中uv作为后起之秀，在安装和解析包的速度这一块真的是一骑绝尘，而pdm在支持PEP新特性这一块相当给力。期待pdm+uv能够一统江湖，结束纷争乱象。

附：pdm项目开发环境自定义命令实例

复制代码

[build-system]
requires = ["pdm-backend"]
build-backend = "pdm.backend"

[dependency-groups]
dev = ["fast-dev-cli>=0.16.2,<1"]

[tool.pdm.scripts]
up = 'pdm update -G :all'
type = "pdm run mypy ."
tree = 'pdm list --tree'
deps = 'pdm sync -G :all {args}'
prod = 'pdm install --prod --frozen'
fresh = {composite = ["up", "deps"]}
test = 'pdm run fast test'
style = {composite = ["ruff format", "ruff check --fix {args}"]}
check = 'pdm run fast check {args}'
lint = 'pdm run fast lint {args}'
bump = "pdm run fast bump patch --commit {args}"
tag = "pdm run fast tag {args}"
start = {composite = ["pre-commit install", "deps"]}
ci = {composite = ["deps", "check", "test"]}

PDM Scripts - PDM