Which Python package manager should I use?

Python has more package managers than most languages. That diversity exists for good reasons, but it makes the initial choice harder than it needs to be. This page cuts through the noise with a decision tree based on what your project actually requires.

The short answer

Use uv. It handles dependency management, virtual environments, Python version management, and package building in a single tool. It follows Python packaging standards, generates cross-platform lockfiles, and resolves dependencies faster than any alternative. For most Python projects in 2026, uv is the right default.

The rest of this page covers when that default does not apply.

Decision tree

    graph TD
    A[Starting a Python project] --> B{Need conda packages?<br/>CUDA, GDAL, HDF5, etc.}
    B -->|Yes| PIXI[pixi]
    B -->|No| C{Existing project?}
    C -->|No| UV[uv]
    C -->|Yes| D{Current tool working?}
    D -->|Yes| STAY[Keep current tool]
    D -->|No| E{Currently using...}
    E -->|Poetry| F{Poetry plugins<br/>with no uv equivalent?}
    F -->|Yes| POETRY[Stay on Poetry]
    F -->|No| MIGRATE_UV[Migrate to uv]
    E -->|pip + requirements.txt| MIGRATE_UV2[Migrate to uv]
    E -->|Pipenv| MIGRATE_UV3[Migrate to uv]
    E -->|conda| G{Need conda-only<br/>packages?}
    G -->|Yes| PIXI2[Migrate to pixi]
    G -->|No| MIGRATE_UV4[Migrate to uv]
  

When uv is not enough

Three situations push you toward a different tool.

You need conda packages

Some dependencies do not exist on PyPI. CUDA toolkits, GDAL, HDF5, and other native libraries require conda channels. Pixi resolves conda and PyPI dependencies together in a single lockfile. It uses uv internally for PyPI resolution, so the workflow feels similar.

See When should I choose pixi over uv? and Why should I choose conda? for detailed comparisons.

You rely on Poetry plugins

Poetry has a plugin system that uv lacks. If your build depends on poetry-dynamic-versioning, a custom plugin for monorepo management, or another plugin with no equivalent, staying on Poetry avoids rework. Check whether uv covers your use case before deciding; many projects that used plugins find they no longer need them.

For projects without plugin dependencies, migrating from Poetry to uv is straightforward.

Your team has a working setup and no reason to switch

Migration has a cost. If your team uses pip-tools, hatch, or PDM and the workflow is stable, switching tools is not urgent. All three follow Python packaging standards, so your pyproject.toml will transfer when you do migrate. Hatch, PDM, and pixi can all use uv as their installer backend, so you can get uv’s speed benefits without changing your workflow.

Tool-by-tool summary

uv

Manages dependencies, virtual environments, Python versions, and package building. Generates cross-platform lockfiles. Replaces pip, pip-tools, pyenv, pipx, and virtualenv with a single binary. Uses PEP 621 metadata exclusively, so project configuration works with any standards-compliant tool.

Choose uv for: new projects, teams standardizing on one tool, CI pipelines where speed matters.

Poetry

Manages dependencies, virtual environments, building, and publishing. Has a plugin ecosystem and a large user base. Poetry 2.0 defaults to PEP 621 for new projects, but many existing projects still use its non-standard [tool.poetry] format.

Choose Poetry for: existing Poetry projects with plugin dependencies, teams already trained on Poetry’s workflow.

See How do uv and Poetry compare? for a detailed breakdown.

pixi

Resolves conda and PyPI dependencies together. Installs native libraries, GPU toolkits, and non-Python software that PyPI cannot distribute. Uses uv internally for PyPI resolution. Has a built-in task runner.

Choose pixi for: data science with native dependencies, GPU/CUDA workflows, projects mixing Python with R or Julia.

See When should I choose pixi over uv?

pip + requirements.txt

The original Python package installer. No lockfile, no virtual environment management, no Python version management. Still works and still ships with Python. For scripts and quick experiments, pip install inside a venv remains a valid approach.

Choose pip for: throwaway scripts, environments where installing additional tools is restricted, legacy systems you cannot change.

If you want faster installs without changing your workflow, uv pip is a drop-in compatible interface that reads the same requirements.txt files. For a fuller migration, moving from requirements.txt to pyproject.toml with uv takes minutes.

hatch

A standards-compliant project manager with built-in environment management and a matrix testing system. Hatch’s build backend (hatchling) is widely used across the ecosystem. Hatch focuses on library development and publishing. It can use uv as its installer backend for faster dependency installation.

Choose hatch for: projects already using hatch, teams that want hatch’s environment matrix for multi-version testing.

PDM

A standards-compliant project manager with lockfile support. PDM follows Python standards closely and can use uv as its installer backend. It also supports PEP 582 (__pypackages__ directory) as an opt-in feature, though PEP 582 itself was rejected by the Python Steering Council in 2023.

Choose PDM for: existing PDM projects with no pressing reason to migrate.

Pipenv

An older tool combining pip and virtualenv with a Pipfile.lock. Development has slowed relative to uv and Poetry. New projects should choose uv instead.

Choose Pipenv for: existing Pipenv projects where migration is not yet practical.

Factors that matter

Standards compliance

Tools that use PEP 621 metadata ([project] table in pyproject.toml) make your project portable. uv, hatch, PDM, and flit all read the same format. Poetry 2.0 supports it and defaults to PEP 621 for new projects, though existing projects using [tool.poetry] are not migrated automatically. Choosing a standards-compliant tool means you can switch later without rewriting your configuration.

Lockfile support

A lockfile pins every transitive dependency to an exact version and records hashes. uv, Poetry, PDM, and pixi all generate lockfiles. pip-tools generates requirements.txt files that serve a similar purpose. Plain pip has no lockfile mechanism.

For reproducible deployments and CI, lockfile support is non-negotiable.

Speed

uv resolves and installs dependencies 10-100x faster than pip and Poetry. The difference is most visible in CI, where every second of install time multiplies across matrix builds. If your CI bill matters, uv pays for itself.

That speed advantage extends beyond the uv CLI. Pixi, hatch, and PDM can all use uv as their installation backend, so even teams that stay on their current tool can benefit from uv’s resolver and installer.

Python version management

uv, pixi, hatch, and PDM can all manage Python interpreters directly. Poetry delegates to pyenv or the system Python. Having one tool handle both the interpreter and dependencies reduces setup steps and avoids version mismatches.

Learn more

• Why are there so many Python packaging tools?
• How do uv and Poetry compare?
• When should I choose pixi over uv?
• What’s the difference between pip and uv?
• How Python tools adopt uv under the hood
• uv reference page