本人目前在用 Poetry，正在考虑迁移到 uv，也考虑 pixi（主要是图 Conda 生态以及可以更方便的测试不同版本的 Python）。
1 个赞
本人使用 Python 做数据科学/机器学习的时候多一些, 对环境依赖严重, 所以仅仅站在环境的角度上来说一下自己的感受:
uv 目前几乎已经完全可以平替 conda 了 (比如 vllm 这样的较为底层的包的官方文档也在近几个月把默认推荐安装方式从 conda 换到了 uv). 本人日常工作环境主要依赖 torch 和 deepspeed, 使用 uv 还是很顺手的. 另外就是我也经常本地写一些小项目, 并且经常在本地环境和云服务器环境中切换, 这时候 uv 轻量化配置的优势就体现出来了.
2 个赞
conda 相比 uv 唯一的优势就是有大量的和 pypi 没有关系的二进制包，比如 node， clang， llvm 之类的二进制包。这个对于没有管理员权限的服务器开发还是有很大的帮助的。
但是现在 2025 年已经有 podman 了，不需要管理员权限也可以在容器内搭建环境，那么 conda 二进制包的优势就没什么太大的意义了。而 uv pyproject.toml + uv.lock 极快的解依赖+装包速度，声明式构建+稳定的锁版本，这个目前在 python 里是具备独一档的优势。
1 个赞
这个对于没有管理员权限的服务器开发还是有很大的帮助的。
确实如此, 我平时使用虚拟机较多疏忽了, 感谢提醒.
那么 conda 二进制包的优势就没什么太大的意义了。
若 Conda 优势不明显, 那确实在我的使用场景里 pixi 的意义也不是特别大了, 因为本人不会开发特别大的项目, 而 uv 完全能满足日常需求. 不知道 pixi 在项目管理上是否有足够的优势.
项目管理用 pyproject.toml + uv.lock 就完全够了吧，不知道 pyxi 作为 uv+conda 的一个 wrapper，在这里能够扮演什么样的角色。
1 个赞
比较好奇容器和虚拟环境哪个开销更小一些，还是说二者其实是等价概念。
不过容器在国内有个小问题要解决：容器的镜像现在是比 Conda 和 PyPI 的镜像要少的，且 Conda 和 PyPI 的镜像大部分时间仅仅是提升下载速度而容器的镜像是用来解决可访达性的。 
uv可以像conda一样切换虚拟环境吗？ 我用uv每次都得source某个项目的虚拟环境
容器比虚拟机开销小啊。如果你的系统是 linux，那么容器基本等于零开销。如果你是 win/mac，那么一个容器的开销等于一个虚拟机，因为容器要运行在虚拟机上。多个容器开销小于多个虚拟机
至于镜像的问题，我从来不用任何国内的镜像，都是直接走代理。
1 个赞
一般都是
uv run xxxx
uv add xxx
这样类似的命令来运行的，uv会自动找到对应的虚拟环境来执行命令，在这个过程中是完全不需要任何类似 source .venv/bin/activate 这样的命令来手动激活虚拟环境的。
当然如果你想同一个项目创建两个虚拟环境，我其实不是很明白为什么一个项目会有两个虚拟环境，但是也是可以的。不过执行起来会麻烦一些
uv venv 会创建第一个 .venv 虚拟环境。 然后你要创建第二个虚拟环境就要用 uv venv .venv-2。然后如果你要用第二个虚拟环境来运行命令，就只能先 source .venv-2/bin/activate 了，才能让 uv 找到 venv-2 作为当前的虚拟环境了。
1 个赞
接楼上:
一般都是
uv run xxxx
uv add xxx
样类似的命令来运行的，uv会自动找到对应的虚拟环境来执行命令，在这个过程中是完全不需要任何类似
source .venv/bin/activate这样的命令来手动激活虚拟环境的。
其实把 uv 当 conda 用也没有什么问题, 你可以找一个专门存放虚拟环境的目录然后 uv venv foo python 3.xx --seed, source .venv/bin/activate, 这样当前激活的foo环境和一个普通的conda环境没多少区别, 然后使用 uv pip install 替代原本的 pip 就好 (但注意这里如果使用pip install, 依旧能改变环境外部的资源)
可能的情形：
- 测试阶段需要在不同的 Python 版本（如 3.11、3.12、3.13）间测试可用性。
- 需要把 C/C++/Rust 代码 bind 到 Python 上，这种情况可能需要每一个 Python 版本都要编译一次。
nix。
我可能不太在乎这个，能用就可以了。
简单一点的话，就一个 nix-shell 就可以了。
前些天在玩键盘，qmk 相关的一般都有 shell.nix，不管是 python 还是其他的，全部都是 nix-shell ，非常方便。
然后使用
uv pip install替代原本的pip就好
用 uv 当然是可以用 uv pip install 。但是更推荐用 uv add 这样的方式来装包。主要 uv add 这个命令更“现代化”，更配合利用 pyproject.toml 声明化管理 依赖的方式。
然后一般来说建议把虚拟环境装在项目的 root 下叫 .venv。因为这样 uv 默认能够自动找到这个环境，就不需要你手动 source .venv/bin/activate。如果装在别的地方，就需要先手动 source 一下才行。
我用PDM Introduction - PDM ，我是用超算中心的，PDM恰好满足我的需求。
PDM 只是在 uv 的 benchmark 里看到过，想了解一下 PDM 在满足超算需求方面相较于 Poetry、uv、Pixi 具体有哪些优势。
这点感觉好奇怪，pytorch 从 2.6 开始也早早抛弃了 Conda（指代 Conda 生态，不仅仅指代 conda 这一个软件），明明 Conda 可以更方便的配置 CUDA 这些非 Python 但却会被 Python 用到的各种东西。因为 PyPI 的构建标签只支持标记 Python 版本、ABI 版本、平台（系统、芯片架构）信息，并不支持标记是打出来的 wheel 文件是基于 CPU 加速还是各种版本的 CUDA 加速还是各种版本的 ROCm 加速构建出来的，所以 torch 只能通过重新定义 Index URL 来区分：
# How to Install PyTorch (2.7.1) on Linux
# CUDA 11.8
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118
# CUDA 12.6
pip3 install torch torchvision torchaudio
# CUDA 12.8
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128
# ROCm
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.3
# CPU Only
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu
- 其实这里三个包都应该写定对应的版本（
torch==2.7.1 torchvision==0.22.1 torchaudio==2.7.1），指令会更长。 - 目前据我所知，
pyproject.toml并没有一个统一的方法来重定义某（几）个包的 Index URL，uv和pdm的配制方法并不互相兼容。 - 不过好消息是
uv提供了uv pip install ... --torch-backend=auto
P.S. 旧版本 pytorch 在 Conda 上面的安装方法：
# CUDA 11.8
conda install pytorch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 pytorch-cuda=11.8 -c pytorch -c nvidia
# CUDA 12.1
conda install pytorch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 pytorch-cuda=12.1 -c pytorch -c nvidia
# CUDA 12.4
conda install pytorch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 pytorch-cuda=12.4 -c pytorch -c nvidia
# CPU Only
conda install pytorch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 cpuonly -c pytorch
uv真这么优秀吗？我一直用conda + pip 感觉没啥痛点呀，conda还能安装指定版本cuda，方便编译啥的