uv vs pixi vs conda for Scientific Python

Your scientific Python project needs CUDA, GDAL, or HDF5. Prebuilt wheels may supply the libraries it needs; a custom native stack may require another package manager. The choice depends on where compatible packages live: PyPI, conda-forge, or both.

Three tools cover the spectrum. uv installs from PyPI. pixi installs from conda-forge and PyPI together. conda installs from conda channels.

What each tool can install

uv resolves packages from PyPI, plus Git URLs, local paths, and private indexes. Wheels can bundle native libraries or depend on NVIDIA’s CUDA packages. uv does not solve arbitrary system packages or install a host GPU driver.

For Python packages with good wheel coverage (NumPy, pandas, scikit-learn, SciPy, PyTorch), uv works well. It is the fastest resolver and installer available, and its pyproject.toml configuration follows PEP 621 metadata, making projects portable to other standards-compliant tools.

pixi resolves conda-forge packages and PyPI packages together in a single lockfile, using uv internally for PyPI resolution. Because conda-forge distributes native libraries alongside their Python bindings, pixi can install CUDA toolkits, GDAL, HDF5, compilers, and non-Python languages in the same project environment.

Project environments live in a .pixi/ directory, with no global conda activate step. Pixi also supports multiple named environments from a single manifest, so a project can define separate gpu and cpu configurations.

conda (including mamba and micromamba) has provided language-agnostic package management for over 14 years. It installs Python, R, Julia, C++ libraries, CUDA toolkits, and compilers. The conda-forge community maintains more than 25,000 packages.

Conda uses a global environment model (conda create -n myenv, conda activate myenv), and its environment.yml format is widely understood across research teams and enterprise infrastructure.

Do you need conda packages?

If all dependencies are available on PyPI with good wheel support, uv is the simpler choice. Standard pyproject.toml, a cross-platform uv.lock, and broad community adoption make it the default for pure Python projects.

If the project needs native libraries that PyPI cannot provide, the choice is between pixi and conda. Both resolve conda-forge packages. The difference is workflow: pixi provides project-local environments, a built-in task runner, and a single lockfile covering conda and PyPI dependencies. Conda provides a global environment model with 14 years of proven infrastructure behind it.

The relationship between pixi and conda is generational rather than adversarial. Pixi comes from prefix.dev, the company behind the mamba solver and conda-forge tooling. It is the modern, project-local evolution of the conda workflow. Conda is the established workhorse that many teams have years of production infrastructure built around.

Scenario comparisons

PyTorch (no RAPIDS, no geospatial)

With uv, configure index routing in pyproject.toml to get CUDA builds on Linux and CPU builds elsewhere. Add torch to [project].dependencies before adding this configuration: tool.uv.sources applies to direct dependencies, not a PyTorch dependency pulled in only through another package.

PyTorch wheels install CUDA runtime libraries, but the host still needs a compatible NVIDIA driver. A system CUDA toolkit is needed for source or JIT compilation that uses nvcc. See How to Install PyTorch with uv for a full walkthrough.

# pyproject.toml (uv)
[[tool.uv.index]]
name = "pytorch-cu128"
url = "https://download.pytorch.org/whl/cu128"
explicit = true

[[tool.uv.index]]
name = "pytorch-cpu"
url = "https://download.pytorch.org/whl/cpu"
explicit = true

[tool.uv.sources]
torch = [
  { index = "pytorch-cu128", marker = "sys_platform == 'linux'" },
  { index = "pytorch-cpu", marker = "sys_platform != 'linux'" },
]

The operating-system markers do not detect GPUs: this configuration also installs CUDA wheels on Linux CPU hosts.

With pixi, PyTorch is available from conda-forge with CUDA runtime libraries as shared dependencies. Declare the CUDA capability expected from the deployment host and constrain the package family:

# pixi.toml
[workspace]
name = "gpu-project"
channels = ["conda-forge"]
platforms = ["linux-64"]

[system-requirements]
cuda = "12.6"

[dependencies]
python = "3.12.*"
pytorch-gpu = "*"
cuda-version = "12.6.*"

The CUDA requirement describes the host; cuda-version constrains environment packages. Neither installs a driver or proves GPU execution. Follow Set Up a GPU Data Science Project with pixi for installation and an accelerator operation check.

With conda, use conda-forge’s explicit GPU package: conda install -c conda-forge pytorch-gpu. PyTorch no longer publishes current releases to its own conda channel. A plain pytorch dependency does not explicitly request the GPU variant.

RAPIDS (cuDF, cuML)

uv can install RAPIDS wheels from PyPI with -cu12 or -cu13 suffixed package names. NVIDIA’s index is also available for releases that require it. When combining RAPIDS with PyTorch, align the CUDA family and dependency constraints of both stacks. See How to Install RAPIDS with uv for platform and hardware requirements.

pixi and conda resolve RAPIDS and its native libraries through conda channels. Compatible package builds must still exist for the selected Python version, platform, and CUDA family.

Geospatial (rasterio, geopandas, GDAL)

The answer depends on which package you need. rasterio and geopandas publish binary wheels that vendor their own GDAL, PROJ, and GEOS, so uv add rasterio geopandas installs and runs on a clean machine with no system GDAL. A reproject-and-write-GeoPackage round-trip works end to end. (geopandas reads and writes through pyogrio, which carries its own bundled GDAL; rasterio carries another. Both copies coexist in one environment without conflict.)

uv struggles only with the standalone gdal package, the osgeo.gdal bindings. It ships no self-contained wheel and needs a system GDAL whose version matches exactly, which pushes the problem outside the Python package manager. The GDAL command-line tools (gdalwarp, ogr2ogr) and GDAL builds with non-default drivers sit outside the wheels too.

pixi and conda install the GDAL C library, its CLI tools, and the Python bindings together. pixi add gdal or conda install gdal resolves the native library, the command-line utilities, and the Python wrapper as one dependency. Reach for them when you need osgeo.gdal, the command-line tools, a driver the wheels omit, or a newer GDAL than the wheels ship. For a project that only uses rasterio or geopandas, uv is enough.

Mixed GPU stacks (PyTorch + RAPIDS + custom CUDA)

uv combines PyTorch’s backend indexes with RAPIDS’ CUDA-suffixed package names. Both must select compatible CUDA runtime dependencies; an index URL alone does not enforce that compatibility. Custom CUDA extensions also need a compatible toolkit and compiler.

pixi and conda resolve CUDA constraints across conda packages in one solver pass. Pixi’s multi-environment features allow defining GPU and CPU variants in a single manifest. PyPI extensions added to that stack still need compatible binaries; neither solver validates their CUDA operations or installs a host driver.

For more on why GPU package installation is complicated, the handbook has a dedicated explanation.

Maturity and ecosystem considerations

These three tools sit at different points on the maturity spectrum.

conda has been in production since 2012. Research labs, pharmaceutical companies, and financial institutions have built CI/CD pipelines, deployment workflows, and team onboarding processes around it. That institutional knowledge has real value. Migrating away from conda means rewriting infrastructure, retraining teams, and accepting risk during the transition. For organizations where conda works, “it works” is a legitimate reason to stay.

conda’s main friction points are speed (the default solver is slower than pixi or uv), the global environment model (which can lead to environment pollution), and Anaconda’s licensing terms for organizations with more than 200 employees. Using Miniforge with conda-forge avoids the licensing issue. Mamba and micromamba address the speed problem as drop-in replacements for conda’s solver.

pixi is newer and under active development. It brings project-local environments, fast resolution, and a unified lockfile to the conda ecosystem. The tradeoff is that pixi.toml configuration is not portable to pip, uv, or poetry (though using pyproject.toml with [tool.pixi] keeps standard [project] metadata portable). Pixi’s adoption is concentrated in scientific computing and ML communities. For more on how pixi compares to uv, see When should I choose pixi over uv?

uv has the broadest adoption across the Python community, the most documentation, and the strongest CI/editor integration. Its limitation is scope: it manages Python packages only. When that scope is sufficient, uv is the leanest option. When it is not, uv cannot stretch to cover the gap.

pixi is backed by prefix.dev, a venture-funded company; uv is made by Astral, which OpenAI acquired in 2026. Both tools are pre-1.0, so teams adopting either should be comfortable with that maturity profile. For a broader discussion of conda’s strengths, see Why should I choose conda?

Decision guide

Start with uv if your dependencies all live on PyPI. If you hit a wall with native libraries, consider pixi for new projects or conda if your team already has conda infrastructure. The two conda-based tools share the same package ecosystem, so the choice between them is about workflow preference and organizational investment, not package availability.

Further reading

• uv reference
• pixi reference
• conda reference
• Why Installing GPU Python Packages Is So Complicated
• How do uv and conda compare? covers the uv-vs-conda pair in depth, including licensing and coexistence
• When should I choose pixi over uv?
• Why should I choose conda?
• Create Your First Python Project with pixi (Tutorial)
• Take Over an Existing Conda Environment (Tutorial)
• Set Up a GPU Data Science Project with pixi (Tutorial)