Development #89980
Remplacer pylint par Ruff ?
0%
Description
On en a parlé au buroparis quelques fois, ruff commence à se stabiliser.
- L'avantage principal comparé à pylint, c'est la rapidité (quasi instanné pour combo, il est possible de l'ajouter aux hooks de pre-commit)
- Il peut à priori se substituer également à black, isort, pyupgrade, ce qui permettrait d'avoir un seul outil.
- En regardant https://docs.astral.sh/ruff/rules/, je pense qu'il y a quelques tests supplémentaires qui pourraient nous intéresser, par exemple https://docs.astral.sh/ruff/rules/#flake8-django-dj ou https://docs.astral.sh/ruff/rules/f-string-in-get-text-func-call/
Historique
Mis à jour par Corentin Séchet il y a 12 jours
- Sujet changé de Ruff ? à Remplacer pylint par Ruff ?
Mis à jour par Robot Gitea il y a 12 jours
- Statut changé de Nouveau à En cours
Corentin Sechet (csechet) a ouvert une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/combo/pulls/255
- Titre : wip: chore: setup ruff (#89980)
- Modifications : https://git.entrouvert.org/entrouvert/combo/pulls/255/files
Mis à jour par Valentin Deniaud il y a 12 jours
Corentin Séchet a écrit :
- L'avantage principal comparé à pylint, c'est la rapidité (quasi instanné pour combo, il est possible de l'ajouter aux hooks de pre-commit)
Je pense que ce serait impossible pour moi de bosser avec les vérifs pylint dans les pre-commit hooks (genre si un truc me bloque parce que je fais un commit avec un import inutilisé). Les pre-commit hooks devraient se limiter à du reformatage mais rien qui vérifie la qualité du code (pour ça, chacun configure son vim/emacs comme il veut).
Mis à jour par Frédéric Péters il y a 12 jours
ruff commence à se stabiliser
Pour le moment c'est uniquement disponible dans debian sid, dans une version qui n'est pas du tout récente (0.0.291).
for transaction in to_expire: # noqa: F402
Je trouve vraiment pas terrible d'avoir à spécifier des codes (vs pylint où c'est désormais possible d'écrire par exemple disable=broad-except), c'est quelque chose qui est prévu dans la roadmap de ruff ?
Mis à jour par Corentin Séchet il y a 10 jours
Valentin Deniaud a écrit :
Je pense que ce serait impossible pour moi de bosser avec les vérifs pylint dans les pre-commit hooks (genre si un truc me bloque parce que je fais un commit avec un import inutilisé).
git commit -n
Ou hooks de pre-push à la place de pre-commit.
Les pre-commit hooks devraient se limiter à du reformatage mais rien qui vérifie la qualité du code (pour ça, chacun configure son vim/emacs comme il veut).
Ça dépend, il y a des gens qui pensent que les hooks doivent empêcher au maximum de commiter du code non-conforme, quelque soit la configuration de l'éditeur de chacun. Perso j'aime bien quand un hook m'économise 5 minutes de run Jenkins sans que j'aie à y penser, c'est green IT, mais c'est une question d'habitude / de politique : ça m'importe peu.
Je trouve vraiment pas terrible d'avoir à spécifier des codes (vs pylint où c'est désormais possible d'écrire par exemple disable=broad-except), c'est quelque chose qui est prévu dans la roadmap de ruff ?
Mis à jour par Emmanuel Cazenave il y a 10 jours
Corentin Séchet a écrit :
Perso j'aime bien quand un hook m'économise 5 minutes de run Jenkins sans que j'aie à y penser, c'est green IT
Idem, c'est cool le gain de temps.
Mis à jour par Frédéric Péters il y a 10 jours
Ok mais il n'y a pas un seul projet où le run pylint (dans jenkins) prend 5 minutes; je préférerais attendre que ruff permette des annotations lisibles (et soit correctement distribué dans debian).
Mis à jour par Valentin Deniaud il y a 10 jours
De mon côté le temps de voir changer brutalement mes outils de travail est révolu : ici je demanderai la tenue d'un vote.
Mis à jour par Corentin Séchet il y a 10 jours
- Statut changé de En cours à Rejeté
Pas de tension de mon côté, c'est une proposition à laquelle je ne tiens pas particulièrement et j'entends très bien les problèmes que ça soulève : je ferme.