Gestion des dépendances Python avec uv

VérifiéSûr

Gère le cycle de vie des dépendances Python : ajout/suppression de paquets, synchronisation de l'environnement et régénération des fichiers de verrouillage avec uv.

Spar Skills Guide Bot
DeveloppementDébutant
1026/08/2026
Claude CodeCursor
#uv#python#dependency-management#lockfile#virtual-environment

Recommandé pour

Notre avis

Gère le cycle de vie des dépendances Python avec uv : ajout, suppression, synchronisation, régénération du lock et exécution de commandes dans l'environnement du projet.

Points forts

  • Maintient automatiquement pyproject.toml et uv.lock en une seule opération, évitant ainsi les erreurs de désynchronisation.
  • uv sync installe exactement ce que le lock file décrit, garantissant des environnements reproductibles.
  • Prise en charge native des dépendances de développement (PEP 735) via uv add --dev.
  • Permet de lancer des commandes dans l'environnement projet avec uv run, sans activation manuelle du virtualenv.

Limites

  • Ne convient pas aux projets gérés par Poetry ou pipenv, dont le lock file et le format des groupes de dépendances diffèrent.
  • La régénération du lock (uv lock) peut entraîner des mises à jour de résolution si les contraintes de versions sont trop larges ; il faut des bornes précises pour éviter les surprises.
  • Ne couvre pas le diagnostic avancé des échecs CI (voir ci-fix).
Quand l'utiliser

À utiliser dès que le projet est basé sur uv (présence de uv.lock ou convention d'équipe) pour modifier les dépendances, synchroniser l'environnement ou exécuter des commandes.

Quand l'éviter

Ne pas utiliser pour un projet géré par Poetry (ou un autre gestionnaire avec son propre lockfile), ni lorsque l'objectif principal est de diagnostiquer et corriger un pipeline CI en échec.

Analyse de sécurité

Sûr
Score qualité92/100

The skill provides documentation and examples for using the uv package manager to manage Python dependencies and environments. It does not contain any destructive, exfiltrating, or obfuscated commands. All commands are standard uv operations (add, remove, sync, lock, run) with legitimate purposes. No sensitive data handling or security bypass instructions are present.

Aucun point d'attention détecté

Exemples

Add a runtime dependency
Add requests to the project with uv and make sure the lock file is updated.
Sync environment after pull
I just pulled the latest changes and uv.lock changed. Sync my environment with uv.
Run tests in project env
Run the test suite in the project's virtual environment with uv.

name: uv description: Manage Python dependencies, lock files, and project environments using the uv package manager. license: MIT compatibility: claude cursor opencode metadata: version: "1.0.0" languages: python audience: developers workflow: automation since: "2026-02-25"

What I do

I handle the full uv dependency-management lifecycle:

  • Add or remove packages — update pyproject.toml and uv.lock in one step
  • Sync the environment — install exactly what the lock file specifies, nothing more
  • Regenerate the lock file — after you edit pyproject.toml, safely re-resolve without unintended upgrades
  • Run commands in the project environment — no manual source .venv/bin/activate needed
  • Initialise a new project — create pyproject.toml and uv.lock from scratch, or migrate from requirements.txt

When to use me

  • Use this skill when the project is uv-managed (for example, uv.lock exists, or the team standard is uv).
  • You want to add, update, or remove a dependency
  • You pulled a branch and need the environment to match the updated lock file
  • You edited pyproject.toml directly and need the lock file regenerated
  • You want to run a script, test suite, or tool inside the project's virtual environment
  • You are starting a new Python project with uv, or migrating from pip/requirements.txt

Use Instead [if available]

  • Use poetry when the project is Poetry-managed (for example, poetry.lock is the lockfile of record).
  • Use ci-fix when your primary goal is diagnosing/remediating a failing CI run instead of general dependency work.

Example usage

/uv add requests
/uv add --dev pytest
/uv remove httpx
/uv sync
/uv lock
/uv run pytest
/uv init

Workflow

Adding and removing dependencies

Add a runtime dependency (goes into [project] dependencies in pyproject.toml):

uv add <package>           # e.g. uv add requests
uv add "<package>>=2.0"    # with version constraint

Add a dev dependency (goes into [dependency-groups] dev — PEP 735, uv's preferred format):

uv add --dev <package>     # e.g. uv add --dev pytest ruff

Dev dependencies are installed in the development environment only and are excluded from production installs. Use --dev for test runners, linters, formatters, and other tooling.

Remove a dependency:

uv remove <package>        # removes from pyproject.toml and updates uv.lock

After every add or remove, uv automatically:

  1. Updates pyproject.toml
  2. Resolves all constraints and regenerates uv.lock
  3. Installs or uninstalls the package in the active environment

Version resolution summary: uv prints the resolved version for each new package, e.g. + requests==2.32.3. If a conflict is detected (a new package's constraints clash with existing ones), uv reports the conflict with the involved packages and constraints — fix the version bounds in pyproject.toml and retry.


Syncing the environment

uv sync installs exactly what uv.lock specifies — no more, no less. It is the canonical way to bring an environment into alignment with the lock file.

uv sync

When to use it:

  • After git pull when teammates updated uv.lock
  • After checking out a branch with different lock file state
  • After manually editing pyproject.toml followed by uv lock (run sync to apply)
  • After cloning a repository for the first time

Already in sync: If the environment already matches the lock file, uv sync exits cleanly with no output. It is safe to run on every git pull as a habit.

Dev vs production sync: By default, uv sync includes dev dependencies. Pass --no-dev to sync only runtime dependencies (mirrors production).

uv sync --no-dev    # production-only install

Regenerating the lock file

Use uv lock after editing pyproject.toml directly — for example, changing a version constraint, adding a new dependency entry by hand, or removing one.

Safe default — no unintended upgrades:

uv lock

By default, uv lock resolves only what has changed. Packages already in the lock file are preserved at their current versions if they still satisfy the updated constraints. This is safe to run after any pyproject.toml edit.

Upgrade all dependencies to latest compatible versions:

uv lock --upgrade

This re-resolves all packages to the latest versions permitted by the constraints in pyproject.toml. Review the lock diff carefully before committing.

Upgrade a single package:

uv lock --upgrade-package <package>    # e.g. uv lock --upgrade-package requests

Upgrades only the named package (and its transitive dependencies if required). All other resolved versions remain unchanged.

When to use each variant:

| Scenario | Command | |---|---| | Edited version constraint in pyproject.toml | uv lock | | Removed a dependency from pyproject.toml | uv lock | | Want to pick up security patch for one package | uv lock --upgrade-package <pkg> | | Periodic refresh of all deps to latest | uv lock --upgrade |

After regenerating the lock file, run uv sync to apply the changes to your environment.


Running commands in the project environment

uv run executes any command inside the project's virtual environment — without requiring manual activation.

uv run <command>

Examples:

uv run pytest                        # run tests
uv run pytest tests/unit/ -v        # with arguments
uv run python src/main.py           # run a script
uv run ruff check .                 # run a tool
uv run python -m mypackage          # module invocation

Auto-sync behaviour: Before running the command, uv automatically syncs the environment if uv.lock has changed since the last sync. This means you never need to remember to run uv sync before executing a command — uv run handles it.

uv run pytest is equivalent to:

source .venv/bin/activate
uv sync
pytest

...but in a single command, with no shell state side-effects.

Replaces manual venv activation: Use uv run <cmd> instead of source .venv/bin/activate && <cmd>. This works consistently across platforms and CI environments.


Initialising a new project

Start a new uv-managed project in the current directory:

uv init

This creates:

  • pyproject.toml with a minimal [project] section
  • uv.lock (empty lock, ready for uv add)
  • .python-version (if Python is pinned)

Pin a specific Python version:

uv python pin 3.12    # writes .python-version with "3.12"

uv reads .python-version automatically on every operation. Pin the version early to ensure consistency across machines and CI.

Migrate from requirements.txt:

  1. Create pyproject.toml if it doesn't exist: uv init
  2. Copy your dependencies into [project] dependencies:
    [project]
    dependencies = [
      "requests>=2.28",
      "click>=8.0",
    ]
    
  3. Generate the lock file: uv lock
  4. Sync the environment: uv sync
  5. Delete requirements.txt once the migration is verified

For dev requirements (from requirements-dev.txt), add them with uv add --dev <package> instead of copying manually, so they land in [dependency-groups] dev.


Tips for Success

  1. uv run replaces venv activation — always use uv run <cmd> instead of activating .venv manually. It works in CI without any setup steps.

  2. uv lock is safe by default — it will not upgrade packages that already satisfy your constraints. Run it freely after any pyproject.toml edit.

  3. Always review the lock diff after --upgradeuv lock --upgrade can pull in breaking changes. Check git diff uv.lock before committing and run your test suite.

  4. Use uv add --dev for test and lint tools — keeping pytest, ruff, mypy, and similar tools in [dependency-groups] dev ensures they are never installed in production.

  5. Run uv sync after every git pull — or just use uv run <cmd> and let auto-sync handle it. Either way, your environment will always match the lock file.

  6. Check uv is installed before starting: uv --version. Install with curl -LsSf https://astral.sh/uv/install.sh | sh or brew install uv if missing.

  7. Commit uv.lock to version control — the lock file is the source of truth for reproducible environments. Never add it to .gitignore.

Skills similaires