Pour info @azarz et @lgrd car j'envisage de faire la même proposition pour r2gg un de ces 4, si ça vous tente 🙂.

Dans CONTRIBUTING.md, dans la partie "Style de code", serait-il possible de justifier les différents choix et d'en discuter ?

Il est clair qu'il faudrait des règles précises pour assurer une uniformité de style. Je suis pleinement partisan d'un code de style homogène, et donc plus facile à lire et maintenir, et des règles bien définies sont le seul moyen d'y arriver. Cependant il serait préférable de nous mettre d'accord sur celle-ci.

Quand on choisit des spécifications écrites pour lecture par des humains, qu'on les implémente avec l'aide d'outils tiers ou pas, ces choix ne sont pas anondins. Il a donc bien débat sur le choix d'une spécification plutôt qu'une autre, et d'une aide à l'implémenttion plutôt qu'une autre.

Pour avoir testé le formattage par black, en accord avec la PEP-8, c'est vraiment la limite à 80 caractères qui me gêne. Si il est effectivement peu lisible d'avoir des lignes trop longues, couper strictement à 80 caractères est rude et contre productif concernant.

Sur le principe d'avoir des pre hook en revanche, c'est parfaitement pertinent (pour jouer les tests unitaires).

Pour le CONTRIBUTING, je pense que la discussion sort même du cadre de ROK4, pour avoir une homogénéïté sur les projets open source gouvernés par l'IGN.

Dans CONTRIBUTING.md, dans la partie "Style de code", serait-il possible de justifier les différents choix et d'en discuter ?

Il est clair qu'il faudrait des règles précises pour assurer une uniformité de style. Je suis pleinement partisan d'un code de style homogène, et donc plus facile à lire et maintenir, et des règles bien définies sont le seul moyen d'y arriver. Cependant il serait préférable de nous mettre d'accord sur celle-ci.

Quand on choisit des spécifications écrites pour lecture par des humains, qu'on les implémente avec l'aide d'outils tiers ou pas, ces choix ne sont pas anondins. Il a donc bien débat sur le choix d'une spécification plutôt qu'une autre, et d'une aide à l'implémenttion plutôt qu'une autre.

Ma PR se veut justement une amorce d'échanges. De ma propre expérience, il faut également doser la nécessaire discussion et le temps du débat sur ce qui peut vite devenir des postures interminables, peu, voire contre-productives surtout si on souhaite d'abord les voir obtenir un consensus à l'échelle de différents projets et équipes de développeurs !

Ainsi, je préfère depuis quelques années être pragmatique en essayant de m'adapter aux "standards de fait" qui s'imposent dans l'écosystème (on parle ici d'outils utilisés voire développés par la Python Software Foundation et Python Packaging Authority), après les avoir éprouvés bien entendu.

Un autre argument est de rendre le projet "expectable" et frictionless dans le cadre d'une dynamique open source : un développeur qui veut embarquer sur le projet, pour une courte ou profonde contribution, se repèrera plus vite si les outils et lignes directrices de contribution sont des choses communément admises.

Pour avoir testé le formattage par black, en accord avec la PEP-8, c'est vraiment la limite à 80 caractères qui me gêne. Si il est effectivement peu lisible d'avoir des lignes trop longues, couper strictement à 80 caractères est rude et contre productif concernant.

Par défaut, black ne respecte pas la règle des 80 caractères (qui est peu suivie depuis déjà quelques années dans les projets ouverts) mais s'est fixé sur 88 avec la possibilité de paramétrer une valeur inférieure.

Dans tous les cas, il faudra en effet préciser la longueur de ligne maximum pour le code (et celle pour les docstrings si différente) dans les contributing guidelines.

Sur le principe d'avoir des pre hook en revanche, c'est parfaitement pertinent (pour jouer les tests unitaires).

Autant je suis un grand fan des git hooks comme l'illustre cette PR, autant je n'ai jamais vu de git hook exécutant les tests unitaires 🤔. Ça me semble ajouter une friction énorme pour quelqu'un qui souhaiterait faire une contribution très légère, typiquement une typo/docstring et qui se verra obligé d'avoir mis en place toute la stack de dév localement.

De mon côté je suis en train de m'éduquer un peu sur les conventions python, à la source. Je suis inexpérimenté dans ce langage pour le moment, alors autant m'assurer que mes futures interventions soient pertinentes.
En tout cas, sur le principe je suis d'accord avec l'utilisation des normes de fait, et surtout celle des PEP, normes officielles dont le processus de mise en place inclus une recherche de consensus. Avec une limitation cependant, qui est de ne pas les appliquer aveuglément sans se poser de question. Nous ne cherchons pas à certifier rok4 ou à le faire entrer dans le noyau de python, donc il faut être prêt à adapter les règles si nous rencontrons une situation où celles-ci sont avant-tout un obstacle. (C'est rare, mais ça arrive.) Bien sûr, dans un tel cas, il faudra en discuter, justifier l'adaptation, et convaincre au moins les contributeurs réguliers, sinon il ne sert à rien d'avoir des règles.
Sur ces paroles, je retourne à mes lectures de PEP. Ce n'est pas le plus stimulant des exercices, mais c'est utile (indispensable ?) et intéressant.

Nous ne cherchons pas à certifier rok4 ou à le faire entrer dans le noyau de python,

Certes non mais comme 99% des projets de bibliothèques ! Heureusement, le noyau de Python est déjà suffisamment rempli ! L'exemple connu est la lecture/écriture de fichiers .wav :D.

Sur ces paroles, je retourne à mes lectures de PEP. Ce n'est pas le plus stimulant des exercices, mais c'est utile (indispensable ?) et intéressant

Bonne lecture ! J'aime bien aussi cet article de Real Python. Après lecture de la PEP8 et dérivés, on pourra faire une PR pour renommer tous les fichiers *.py 😃.

Pour ma part, à vous lire tous les deux et à relire ma proposition, je me rends compte que ma PR est trop "grosse" et embarque trop de hooks d'un coup, issus des nombreux projets que je (on) mène en Python à Oslandia et ailleurs, notamment la GPF, surtout si vous n'avez pas l'habitude de ce langage, de son écosystème ou des bibliothèques open-source.

Que pensez-vous de continuer ici la discussion et que je fasse une PR par git hook ? On pourrait ainsi ajouter celui proposé par poetry (https://python-poetry.org/docs/pre-commit-hooks/)... qui est d'ailleurs un choix opinionated qui pourrait également être discuté 😉.

J'ai oublié de mentionner que cette PR, comme d'autres à venir, fait partie de changements qui visent à "sécuriser" le projet sur lequel repose l'un des composants développés pour la GPF et dont nous avons la responsabilité (Altimétrie mais potentiellement d'autres).

Contrairement à ce que j'ai pu dire, découper la PR va effectivement être plus simple. Pour les tests unitaires je me suis peut être emballé 😇

Je te laisse le découper ?

Je ferme ici car l'essentiel est désormais en place avec même la connexion à pre-commit.ci qui déclenche des MAJ trimestrielles des hooks.