Outil Python scientifique moderne en 2026 : UV, Ruff et Ty

Points à retenir clés

• UV est devenu le gestionnaire de packages Python par défaut pour le calcul scientifique – 10 à 100 fois plus rapide que le PIP, avec des fichiers de verrouillage déterministes qui rendent la production de flux de travail de recherche reproductible.
• Ruff remplace le noir, l’isort, le flake8, le pyupgrade et le flocon automatique dans un seul binaire basé sur la rouille. Scipy, Pandas et d’autres bibliothèques scientifiques majeures l’utilisent aujourd’hui.
• ty (publié en décembre 2025) est 20 à 100 fois plus rapide que MyPY et utilise une garantie progressive qui ne cassera pas le code non annoté, idéal pour migrer les bases de code de recherche.
• PyProject.toml est désormais la source unique de configuration de l’ensemble de la chaîne d’outils, remplaçant les fichiers de configuration dispersés comme .flake8, .isort.cfg et mypy.ini.
• Pour le calcul scientifique en particulier, Conda reste nécessaire pour les dépendances non-Python (MPI, CUDA, HDF5), et Pyright est toujours le choix le plus sûr jusqu’à ce que TY atteigne la version 1.0.

Si vous exécutez des flux de travail Scientific Python en 2026, votre chaîne d’outils a fondamentalement changé. Les packages que vous utilisez pour le calcul – numpy, scipy, fipy et le reste – sont les mêmes. Mais la façon dont vous les installez, les gérez, les peluches et les types de vérification est différente de ce que la plupart des didacticiels, des guides plus anciens et des ordinateurs portables universitaires recommandent encore.

Astral, la société derrière Python le plus populaire de Python (Ruff), a créé trois outils qui couvrent désormais l’ensemble du flux de travail des développeurs : UV pour la gestion des packages, Ruff pour le peluche et la mise en forme, et ty Pour la vérification du type. Ensemble, ils remplacent Pip, Venv, Black, Isort, Flake8 et MyPy. C’est six outils réduits en trois, tous configurés à partir d’un seul fichier pyproject.toml.

Cet article couvre la chaîne d’outils Python scientifique moderne en 2026. Il explique ce que fait chaque outil, pourquoi le changement s’est produit et comment tout configurer, y compris les bizarreries et les limitations qui comptent pour le calcul scientifique. Si vous configurez un nouveau projet de simulation, migrez une base de code existante ou rattrapez votre retard après le guide « Scientific Python Ecosystem » (voir article #364), c’est la mise à jour pratique dont vous avez besoin.

Le paysage de l’outillage moderne

Jusqu’en 2024 environ, le flux de travail du développeur Scientific Python ressemblait à ceci :

• Gestion de packages : PIP avec PIP-Tools ou Poetry
• Environnements virtuels : VENV ou VirtualEnv
• Gestion des versions de Python : pyenv ou pyenv-virtualenv
• Linting : flake8, puis pydocstyle, plus pylint pour les vérifications de style
• Formatage : noir et Isort (et plus tard, Autopep8 et PyUpgrade)
• Vérification des types : myPy

Cela signifiait installer six packages Python distincts, maintenir des fichiers de configuration distincts et attendre des étapes de résolution séquentielles. Un simple pip install pourrait prendre quelques minutes. Running Black, puis Isort, puis Flake8, alors MyPy pourrait prendre encore plus de temps.

Le quart de travail a commencé lorsqu’Astral a sorti Ruff en 2023. Ruff a été écrit dans Rust, conçu pour remplacer simultanément Black, Isort, Flake8, PyUpgrade et Autoflake, et a couru des ordres de grandeur plus rapidement que les alternatives basées sur Python. Ce succès d’adoption a donné à Astral l’élan nécessaire pour construire un écosystème complet : les UV pour la gestion des paquets et la vérification des types.

Fin 2025 et début 2026, la convergence était complète. Le Guide de développement scientifique Python recommande désormais officiellement Ruff Pour les vérifications de style et TY pour la vérification du type. Scipy et Pandas ont adopté Ruff. UV a dépassé la poésie dans l’adoption au sein des équipes de calcul scientifique. L’ancienne pile n’est pas morte – elle fonctionne toujours – mais ce n’est plus la valeur par défaut pour les nouveaux projets.

Pourquoi pyproject.toml est important

L’un des changements pratiques les plus importants est le modèle de configuration. L’ancienne configuration dispersée de la pile dans cinq fichiers ou plus :

• .flake8 pour les règles de peluche
• .isort.cfg pour le tri des importations
• mypy.ini pour le comportement de vérification de type
• setup.cfg pour les métadonnées du package
• pyproject.toml (partiellement, pour les systèmes de construction)

L’outillage moderne centralise tout dans pyproject.toml. Un seul fichier définit le package, les dépendances, les outils de développement et la configuration de l’outil. Cela rend les projets plus faciles à partager, à cloner et à entretenir, exactement ce dont les équipes de recherche ont besoin lorsqu’elles publient du code ou à bord des nouveaux étudiants.

UV : gestion des packages qui fonctionne réellement

uv est un gestionnaire de packages basé sur la rouille construit par Astral. Il remplace PIP, PIP-Tools, PIPX, PYENV et VirtualEnv dans un seul binaire rapide. Contrairement à PIP, uv n’exige pas que Python soit installé en premier : il peut amorcer un interpréteur Python et gérer les versions aux côtés des dépendances.

Pourquoi les chercheurs changent

Les principales raisons pour lesquelles les chercheurs et les développeurs choisissent uv :

1. Vitesse. uv installe des packages 10 à 100 fois plus rapidement que le PIP, principalement grâce à une résolution parallèle et à une mise en cache agressive. Cela est important dans les pipelines CI où le temps d’installation a un impact direct sur la rotation des développeurs.
2. Verrouiller les fichiers. Un seul fichier uv.lock enregistre les versions résolues exactes de chaque dépendance, y compris les sous-dépendances. La validation de ce fichier dans Git rend votre environnement entièrement reproductible, une exigence pour les simulations publiées.
3. Gestion des versions de Python. uv peut télécharger et gérer des interpréteurs Python, éliminant ainsi le besoin d’outils distincts comme PYENV.
4. Compatible PIP. Des commandes comme uv pip install fonctionnent avec requirements.txt, simplifiant la migration des projets existants.

Configuration des UV

Le flux de travail typique d’un nouveau projet Python scientifique ressemble à ceci :

# Install uv (curl pipe to sh, cross-platform)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Create a project with a specific Python version
uv init my-simulation --python 3.11
cd my-simulation

# Add core scientific dependencies
uv add numpy scipy matplotlib

# Add domain-specific libraries
uv add fipy mpmath

# Add development tools
uv add --group dev pytest ruff ty

# Generate and commit a lockfile
uv lock
git add pyproject.toml uv.lock
git commit -m "Initial project with pinned dependencies"

uv sync s’installe à partir du fichier de verrouillage, assurant des reproductions déterministes. Toute personne clonant le référentiel et exécuté uv sync obtient exactement les mêmes versions résolues.

La bizarrerie de la compilation de bytecode

Voici où uv se comporte différemment du PIP et où les équipes de calcul scientifique ont heurté des murs inattendus.

uv reporte la compilation de bytecode à la première exécution. Lorsque uv installe un package, il stocke le bytecode précompilé dans un cache mais ne compile pas tous les fichiers immédiatement. Cela rend uv les installations environ 3 à 4 fois plus rapides que PIP. Cependant, la première importation d’une bibliothèque (en particulier NumPy ou Scipy) peut être environ 2,5 fois plus lente qu’une copie installée par PIP, car le bytecode est compilé au moment de l’importation.

Pour le développement interactif, ce ralentissement est généralement imperceptible. Pour les pipelines CI, les scripts de travaux HPC ou les serveurs de production qui importent NumPy ou Scipy à chaque exécution, la Quirk compte. Le correctif est simple : ajoutez --compile-bytecode à votre commande de synchronisation.

Contexte réel : l’équipe de données de Plotly a documenté ce problème exact après avoir adopté uv en production. Leurs serveurs de production ont vu des importations nettement plus lentes de NumPy jusqu’à ce qu’ils ajoutent le drapeau. Consultez le billet de blog de Plotly sur les bizarreries UV pour la ventilation technique complète.

Le comportement de l’index exclusif

uv traite --extra-index-url les entrées comme exclusives par défaut, après PEP 0708. Cela signifie que si un package existe dans votre index principal, uv ne vérifiera jamais l’index supplémentaire pour cela. Cela protège contre les attaques de dépendance – un acteur malveillant ne peut pas remplacer un package hébergé sur un index bien connu par un miroir compromis. Mais cela brise également les pipelines existants requirements.txt qui dépendent d’indices supplémentaires pour les packages de secours.

Si votre laboratoire utilise un index de package privé ou un index compatible CONDA, vous devrez configurer explicitement le index-strategy dans pyproject.toml. Sans cette configuration, uv peut ne pas résoudre les packages qu’il s’attend à trouver sur l’index supplémentaire.

Quand les UV ne suffisent pas

uv gère les packages Python et les interprètes Python. Il ne gère pas les dépendances système non-python : bibliothèques C et C++, compilateurs Fortran, MPI, boîtes à outils CUDA, HDF5, FFTW ou bibliothèques graphiques.

Pour ces dépendances, Conda reste la norme. Le modèle recommandé consiste à utiliser uv pour les packages Python et Conda (ou Pixi) pour les dépendances au niveau du système. De nombreuses équipes scientifiques associent les deux outils – Conda pour la pile système, uv pour la couche Python.

Si votre projet implique des dépendances non-Python telles que MPI, CUDA ou HDF5, consultez le guide associé sur Gestion des dépendances en python scientifique, qui couvre conda, lockfiles et quand utiliser chaque outil.

Ruff : le linter qui remplace six outils

Ruff est un linter et un formateur basés sur la rouille construits par Astral. Il remplace le noir (formatage), les isortes (tri de l’importation), le floke8 (vérification de style), le pyupgrade (suppression du code mort) et le flocage automatique (suppression de variables inutilisées) dans un seul binaire qui s’exécute 10 à 100 fois plus rapidement que l’ancien combiné. empiler.

Cela le rend particulièrement attrayant pour l’informatique scientifique, où de grandes bases de code avec des versions mixtes de Python et des modules hérités peuvent prendre plusieurs secondes pour s’aligner sur les outils traditionnels. Ruff le fait en quelques millisecondes.

Les bibliothèques scientifiques utilisent déjà Ruff

Ruff n’est plus seulement un linter de cadres Web. Les grandes bibliothèques scientifiques l’ont adopté :

• Scipy — L’équipe de base de la bibliothèque de méthodes numériques a migré vers Ruff.
• Pandas : utilise Ruff pour l’application des styles dans toute la base de code.
• Fastapi et visage en étreignant — tous deux utilisent Ruff comme seul formateur et linter.

Cette adoption est importante car elle signale que Ruff gère les cas de code scientifique – longues docstrings, annotations de type complexes, importations héritées de style Python-2 – sans perdre l’exactitude ni introduire de bogues de mise en forme. La documentation officielle de RUFF répertorie les trois bibliothèques en tant qu’adopteurs. Consultez la officiel ruff docs pour la liste complète.

Configuration

Ruff configure entièrement à partir de pyproject.toml :

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "N", "W", "UP", "RUF"]
ignore = ["E501"]

[tool.ruff.format]
quote-style = "double"

Le tableau select spécifie les jeux de règles à activer. E et F COVER PEP 8 Erreurs et vérifications Pyflakes. I Gère le tri des importations (remplaçant Isort). N Applique les conventions de dénomination. UP Exécute la modernisation de style pyupgrade. RUF Ajoute des règles spécifiques à Ruff. La ligne ignore supprime E501 (trop de ligne) car Ruff délègue la longueur de ligne au formateur, en gardant la linter rapide.

Migration depuis le noir + l’isort + le flocon8

La suppression de l’ancienne pile est simple. Après avoir installé RUFF, vous pouvez remplacer les commandes :

# OLD stack
black .
isort .
flake8 .
pyupgrade --py38 src/

# NEW stack
ruff check .
ruff format .

ruff check Gère toutes les vérifications de style. ruff format Gère tout le formatage. C’est deux commandes au lieu de quatre, exécutant un binaire au lieu de quatre distincts.

Le guide de développement scientifique Python recommande explicitement de migrer de Flake8 à Ruff pour les vérifications de style. Consultez leur guide de sécurité et de développement pour la recommandation officielle.

TY : vérification du type sans douleur

ty est le vérificateur de type de nouvelle génération d’Astral, publié en décembre 2025. Il remplace myPY en tant que vérificateur de type statique recommandé dans l’écosystème Astral. Il est écrit en rouille et conçu pour être rapide, strict par défaut et compatible avec un code non annoté.

La vitesse de gain

L’avantage le plus spectaculaire de TY est la vitesse. Dans un benchmark du monde réel par un utilisateur qui a migré de MyPy vers TY sur une base de code Python scientifique réelle, MyPY a pris 46 secondes et TY a effectué la même vérification en 2,19 secondes – environ 20 fois plus rapide. Consultez la référence complète dans The Stackademic Migration Post.

Cela compte car la vérification des types est souvent l’étape CI la plus longue dans un flux de travail Python. Réduire 46 secondes à 2,2 secondes réduit les temps de file d’attente des CI, permet aux développeurs d’obtenir des commentaires plus rapides et rend la vérification complète du type dans les branches où même les vérificateurs de type lents auraient été ignorés.

La garantie graduelle

Contrairement à myPY, Ty implémente une garantie progressive : il ne fera pas apparaître d’erreurs sur le code qui n’a pas d’annotations. Si un module contient def calculate(x, y): return x + y sans indices de type, TY le traite comme non typé et ne se plaint pas des annotations manquantes. Ceci est idéal pour migrer les bases de code scientifiques qui ont des modules partiellement typés – un modèle commun dans le code de recherche où le moteur de simulation de base est tapé, mais pas les scripts d’assistance et les ordinateurs portables.

le manuel officiel de TY explique en détail la garantie progressive. Le point clé est que l’ajout d’annotations de type à un module n’entraîne pas TY pour signaler des erreurs dans ce module. MyPy fait le contraire : il signale des erreurs sur toute fonction non annotée qu’il rencontre, ce qui casse les bases de code existantes dépourvues d’annotations complètes.

Conformité aux spécifications : le compromis

Voici le compromis que vous devez comprendre avant de mettre TY dans CI.

Selon Une comparaison complète de MyPy, Pyright, Ty et Pyre, la conformité des spécifications Python de Ty se situe à environ 53 %, tandis que Pyright atteint environ 98 % et que MyPy atteint environ 58 %. Cela signifie que Ty ne couvre que la moitié des fonctionnalités de spécification de frappe, et il peut manquer des cas de bord que Pyright capture.

Jusqu’à ce que TY atteigne la version 1.0, la stratégie CI recommandée est une approche à deux couches :

1. Développement local : utilisez Ty pour une rétroaction rapide (vérifications de 2 secondes).
2. Pipes de CI : utilisez Pyright pour une couverture complète des spécifications (attrape les échecs de TY).

Cela vous donne à la fois de la rapidité et de l’exactitude. Une fois que TY atteint 1,0 et que sa conformité aux spécifications s’améliore, vous pouvez compter uniquement sur TY pour CI.

Configuration

Ty configure à partir de pyproject.toml :

[tool.typer]
python-version = "3.11"
strict = true

L’indicateur strict active toutes les vérifications strictes du mode (colonne implicite, non-un-typé-def, etc.). Voir Le manuel TY pour la référence de configuration complète.

Guide de migration : de l’ancienne pile au nouveau

Voici la comparaison pratique avant et après. Si vous utilisez actuellement PIP, VenV, Black, Isort, Flake8 et MyPy, ce tableau montre exactement ce qui remplace chaque outil.

Migration étape par étape

Voici le chemin de migration concret pour un projet existant :

# 1. Install uv and Ruff
uv pip install uv ruff

# 2. Create pyproject.toml (replacing setup.cfg)
cat >> pyproject.toml <<EOF
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.backends._deprecated"

[project]
name = "my-simulation"
version = "0.1.0"
dependencies = [
    "numpy",
    "scipy",
    "fipy",
]
EOF

# 3. Add Ruff config
cat >> pyproject.toml <<EOF

[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "N", "W", "UP"]
ignore = ["E501"]
EOF

# 4. Add ty config
cat >> pyproject.toml <<EOF

[tool.typer]
python-version = "3.11"
strict = true
EOF

# 5. Run uv sync to manage dependencies
uv sync

# 6. Run Ruff to check and format existing code
ruff check .
ruff format .

# 7. Run ty locally for fast type feedback
ty check .

Ce chemin fonctionne car la sortie de Ruff est presque identique au style de mise en forme de Black, de sorte que le code formaté semble familier. La garantie graduelle de TY signifie qu’elle ne cassera pas les modules non annotés lors de la migration. Vous pouvez ajouter des annotations de type de manière incrémentielle sans crainte d’erreurs de surface TY sur le code que vous n’avez pas encore tapé.

Si votre projet s’appuie sur requirements.txt, notez que uv peut s’installer à partir de uv pip install -r requirements.txt. Mais pour la reproductibilité à long terme, générez un fichier uv.lock et éloignez-vous de requirements.txt. Consultez le guide connexe sur Gestion des dépendances en Python scientifique pour en savoir plus sur les fichiers de verrouillage et la reproductibilité.

Ce que nous recommandons : un cadre de décision

Toutes les équipes ne doivent pas adopter les trois outils simultanément. La bonne pile dépend des exigences de votre projet. Utilisez ce cadre de décision pour choisir :

1. Avez-vous besoin de dépendances non-Python ? (MPI, CUDA, HDF5, C++, compilateurs Fortran)
   • Oui : utilisez conda pour ces dépendances. Vous pouvez toujours utiliser uv pour les packages Python aux côtés de Conda.
   • No : passez à la question suivante.
2. Publiez-vous un package Python sur Pypi ?
   • Oui : envisagez la poésie pour les flux de travail de publication matures, ou uv pour des installations plus rapides pendant le développement. Les deux prennent en charge la publication PYPI.
   • Non : uv est le choix par défaut pour les nouveaux projets de recherche.
3. Travaillez-vous dans des pipelines CI/CD là où le temps d’installation est important ?
   • Oui : utilisez uv. Les gains de vitesse (10 -100 × sur pip) réduisent directement les temps de file d’attente des CI.
   • Non : uv ou la poésie peut fonctionner selon la familiarité de l’équipe.
4. Quelle est l’importance de la couverture complète des spécifications de type de vérification de type dans CI ?
   • High : utilisez Pyright pour CI, TY pour le développement local. Cela vous donne à la fois de la rapidité et de l’exactitude.
   • low : Ty seul est suffisant pour la plupart des bases de code de recherche.

Pour la plupart des nouveaux projets de recherche, la pile recommandée est :

• UV pour la gestion des packages et les fichiers de verrouillage
• Ruff pour les peluches et le formatage
• TY pour la vérification des types locaux (rétroaction rapide)
• Pyright pour la vérification du type CI (couverture complète des spécifications)

Cette combinaison vous donne de la rapidité, de l’exactitude et de la reproductibilité, les trois piliers de la qualité des logiciels de recherche.

Limitations : quand s’en tenir aux anciens outils

La pile moderne est puissante, mais ce n’est pas un remplacement universel. C’est à ce moment-là que vous devez conserver les anciens outils :

Conda pour les dépendances non-Python

UV gère les packages Python et les interprètes Python. Il ne gère pas les bibliothèques C compilées, les compilateurs Fortran, les boîtes à outils CUDA, HDF5, FFTW ou graphiques. Pour ceux-ci, Conda (ou Pixi) reste la norme pour le calcul scientifique. De nombreuses équipes utilisent Conda pour les dépendances système et uv pour les packages Python dans le même environnement.

myPY pour une couverture complète des spécifications

Jusqu’à ce que TY atteigne la version 1.0 et comble son espace de conformité des spécifications, MyPY ou Pyright est le choix le plus sûr pour les environnements CI nécessitant une couverture complète de vérification de type. Utilisez TY pour le développement local où la vitesse est importante et le Pyright (ou MyPy) pour l’IC lorsque l’exactitude est importante.

Poésie pour l’édition Pypi

Si vous publiez des packages Scientific Python sur Pypi, Poetry a toujours des workflows de publication mûrs, des groupes de dépendances et un pipeline de construction bien documenté. uv prend en charge la publication Pypi, mais ses flux de travail sont plus récents et moins documentés que ceux de Poetry. Si votre équipe valorise la documentation établie et les longs enregistrements de production, la poésie peut toujours être le meilleur choix pour la publication de votre flux de travail.

Résumé et étapes suivantes

La chaîne d’outils Scientific Python a mûri. La pile alimentée par la rouille – UV, Ruff et TY – remplace les anciens outils fragmentés par quelque chose de plus rapide, plus simple et mieux intégré. Voici les plats à emporter :

1. UV est le gestionnaire de packages par défaut pour les nouveaux projets. Utilisez --compile-bytecode sur les serveurs et les pipelines CI. Utilisez Conda à ses côtés pour les dépendances non Python.
2. Ruff remplace Black, Isort, Flake8, PyUpgrade et Autoflake. Scipy et Pandas l’utilisent déjà. Configurez tout à partir de pyproject.toml.
3. ty est le vérificateur de type le plus rapide disponible, 20 × plus rapide que MyPy. Utilisez-le localement. Utilisez Pyright pour CI jusqu’à ce que TY atteigne 1,0.
4. PyProject.toml est la seule source de configuration. Les trois outils lisent. Plus de fichiers de configuration dispersés.

Si vous lancez un nouveau projet de simulation, adoptez la pile moderne dès le premier jour. Si vous migrez un projet existant, suivez le chemin étape par étape ci-dessus – la sortie de mise en forme de Ruff est presque identique à celle de Black, et la garantie progressive de Ty signifie que vous ne cassez pas le code existant pendant la transition.

Pour un contexte plus large sur la pile scientifique de la bibliothèque Python qui se trouve au-dessus de cet outillage, consultez le Guide d’écosystème Python scientifique, qui couvre NumPy, Scipy, Sympy, MatPlotlib, Jupyter et Apprendre le scikit. Pour une couverture plus approfondie de la gestion des dépendances et des fichiers de verrouillage, consultez le guide Gestion des dépendances dans Scientific Python. Et pour les meilleures pratiques de maintenance qui se marient bien avec la chaîne d’outils moderne, lisez le guide des meilleures pratiques pour maintenir le code scientifique.

L’écosystème scientifique de Python ne va nulle part. Mais la façon dont vous travaillez avec cela a changé, et l’adoption de la pile moderne vous offre des constructions plus rapides, une configuration plus simple et une meilleure reproductibilité, le tout sans modifier les bibliothèques que vous utilisez pour le calcul.

Références et lectures complémentaires

• Ruff Documentation — Guide officiel pour le linter et le formateur basés sur la rouille.
• référentiel uv github — code source officiel et documentation des fonctionnalités.
• Packaging Python en 2025 : présentation des UV — Franziska Hinkelmann aperçu technique de la conception et de la philosophie des UV.
• Gestionnaire de packages UV Python : bizarreries et leçons Apprentissage — L’expérience d’adoption dans le monde réel de Plotly avec les UV.
• configuration du projet Python 2026 : UV, Ruff, TY, Polars – Guide de configuration étape par étape pour la pile moderne.
• Manuel de ty — Manuel officiel couvrant les capacités de TY, la garantie progressive et Intégration du code VS.
• Desseurs de type Python comparés – Comparaison complète de MyPY, Pyright, TY et Pyre avec les données de conformité des spécifications.
• Je suis passé de MyPy à TY (46s → 2.19s) — benchmark de vérification de type dans le monde réel sur une base de code Python scientifique.
• Guide de développement scientifique Python — Recommandations officielles de la communauté pour Ruff et TY.