🧫 Ajout d'un linter Python

[Aeris1One]

Cette PR est soumise à discussion quant-aux réglages.
Dans l'état actuel, le linter vérifie non seulement que le code Python est correct (pas de fonction appelée non définie par exemple), indique les morceaux de code inutiles (une fonction importée mais non utilisée) mais ausi vas reformater selon la PEP-8 pour que le code soit lisible par les personnes habituées à travailler en PEP-8.

Je pense que ça permettrai d'avoir un code bien plus uniforme, là où je sais que chacun à ses petites habitudes. Cependant il y avait déjà eu le débat sur Discord à propos de certains formatages, pas forcément autorisés par la PEP-8 qui semble pour certains plus clairs que d'autres.

Que faisons-nous ?

[ascpial]

Je penses que il ne faudrait pas mettre de formatage automatique pour la pep-8, vu que les collaborateurs principaux ne souhaitent pas l'utiliser. De toute manière, si il faut l'ajouter on pourra toujours le faire plus tard.
Par contre la vérification de code peut être une bonne idée, même si une PR avec du code contenant des erreurs me semble assez stupide...

[VForiel]

Le passage en pep8 peut être intéressant pour les releases, mais en effet je suis d'accord avec ascpial, pendant les phases de dev, chacun bosse sur son système avec ses propres habitudes

[Aeris1One]

Justement, pendant ton développement tu fais ce que tu veux, mais dès que tu part sur la branche béta ou la branche master il formate en suivant la pep8
Et puis ça arrive de push du code avec des erreurs, c'est même très fréquent, vaut mieux un garde-fou ascpial :)

[VForiel]

Dans ce cas c'est bon pour moi

[Aeris1One]

L'objectif du linter est d'obtenir un code bien plus lisible par les humains, par exemple, les premières lignes du start.py donneraient, avec seulement le linter black:

[Aeris1One]

Je suis en train de faire quelques tests d'efficacité de mon côté, j'ai donc repassé la PR en WIP

[ascpial]

Si ça peut aider les autres à utiliser la pep 8 why not du coup xD

[Aeris1One]

Très sérieusement, si des trucs sont contre la PEP8 mais nous conviennent mieux que ce que dit la PEP8 et/ou sont plus lisible, on les gardera

[Aeris1One]

Donc, j'ai laissé comme linters :

• Black, qui utilise sa propre feuille de style, inspirée de la PEP8 mais aussi d'autres conventions comme le Google Python Style Guide, pour rendre le code bien plus lisible (voir la screen ci-dessus)
• PyLint, qui détecte les erreurs dans le codes, mais également quelques erreurs de style

Black fait de l'auto-fix, il fera un commit dans chaque PR et à chaque push dans master et beta pour s'assurer que tout est ok !
PyLint ne fait pas d'autofix, et je suis en train de me battre avec lui (la note du bot est d'environ 5/10 actuellement)

[VForiel]

LGTM mais idk comment tester ça 😅

[Aeris1One]

Je l'ai déjà testé de mon côté à plusieurs reprises, il tourne sur la branche master de Aeris1One/Gipsy : https://github.com/Aeris1One/Gipsy/actions/runs/2928876343

Black est en failed à cause des "import bot import checks" qui sont foirés. J'ai ouvert un PR, voila ce que ça donne sur une PR : https://github.com/Aeris1One/Gipsy/pull/1

[ascpial]

Aller aller on révise faut avoir des meilleurs notes

[Aeris1One]

Je vais ouvrir une autre PR pour le refactor, j'ai réussi à faire passer start.py de 6.75 à 10/10 pour l'instant, et utils est en bonne voie.
Le gros problème est que certaines fonctions redéfinissent des accès globaux (beaucoup de fonctions prennent un argument noté "config" par exemple, qui est défini globalement, et le linter aime pas du tout qu'on l'overwrite localement)

[VForiel]

Ca m'a l'air tout bon, mais y'a tellement de soucis dans le code que PyLint et Black galèrent d'après les logs de l'action 😂

[Aeris1One]

Le deuxième exemple (dans la PR) crash parce qu'évidemment mon fork peut pas push dans l'upstream (la PR étant Gunivers -> Aeris1One) mais ici normalement il n'y aura pas de problème.

Black crashait à cause des "import bot import checks" donc il n'arrivais pas à revoir le style de ces fichiers totalement incorrects, il aurait dû exit sans erreur. PyLint exit avec une erreur et c'est totalement normal puisque le score est inférieur à 8/10.

[Aeris1One]

Si cette PR est merge, le résultat de l'action devrait ressembler à ça : https://github.com/Aeris1One/Gipsy/runs/8034509506

[Aeris1One]

Le check des conventions et des messages d'information de style sont désactivés.

Une seconde Action en mode dégrade à été créee de manière à pouvoir fonctionner sur des PRs provenant de forks (et sur lesquelles on a pas de droit en écriture, donc pas possible d'autofix). Pour ces PR, l'autofix se fera au moment du merge.