uv vs pixi vs conda for Scientific Python

Your scientific Python project needs CUDA, GDAL, or HDF5, and pip install cannot help. Which tool should manage those native dependencies alongside your Python code? The answer depends on where your 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. It cannot install non-Python dependencies like the CUDA toolkit, GDAL, or HDF5.

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, 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. PyTorch wheels bundle their own CUDA runtime, which makes installs larger but self-contained. 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'" },
]

With pixi, PyTorch is available from conda-forge with CUDA as a separate, shared dependency. The solver matches CUDA versions across packages automatically:

# pixi.toml
[dependencies]
pytorch-gpu = "*"
cuda-version = "12.6.*"

With conda, the traditional command was conda install pytorch pytorch-cuda=12.4 -c pytorch -c nvidia. PyTorch 2.5 was the last release published to the pytorch Anaconda channel. conda-forge now carries PyTorch builds, so conda install -c conda-forge pytorch is the path forward for conda users.

RAPIDS (cuDF, cuML)

uv can install RAPIDS via --extra-index-url=https://pypi.nvidia.com with -cu12 or -cu13 suffixed package names. When combining RAPIDS with PyTorch, dependency conflicts between NVIDIA’s index and PyTorch’s index are possible. See How to Install RAPIDS with uv for details.

pixi and conda handle RAPIDS well. RAPIDS was originally conda-only, and conda-forge RAPIDS packages resolve together with the CUDA toolkit in a single solver pass. No index juggling required.

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 requires separate index configurations for PyTorch and RAPIDS, each with their own URL and package naming conventions. Configuration gets complex, and dependency conflicts between indexes are a real risk.

pixi and conda resolve CUDA versions across all packages in one solver pass. Pixi’s multi-environment features allow defining GPU and CPU variants in a single manifest. Conda provides the same solver advantage but requires separate tools like conda-lock for cross-platform lockfiles.

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
• 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)