formattage markdown

docs/GuideDeveloppeurs.md

@@ -1,6 +1,5 @@
 # Documentation pour les développeurs ScoDoc
 
-
 Informations pour les développeurs souhaitant étendre ou modifier ScoDoc.
 
 ## Informations générales
@@ -14,15 +13,16 @@ Informations pour les développeurs souhaitant étendre ou modifier ScoDoc.
   * [Discussions pour la future gestion des absences](IdeesGestionAbsences.md)
   * [Anciennes discussions sur la gestion des plannings](IdeesGestionPlannings.md)
 
- 
 ## Développer sur ScoDoc
 
 Quelques conseils, indications et mémos pour les développeurs sur ScoDoc version 9.
 
 ### Installation d'un serveur de développement
+
 [Quelques conseils pour configurer votre serveur de développement](ConseilServeurDev.md)
 
 ### Style et formatage du code
+
 L'ancienneté de la base de code a rendu le style un peu incohérent, mais cela 
 s'est nettement amélioré avec ScoDoc 9 (respect PEP 8).
 
@@ -30,6 +30,7 @@ Le code DOIT être formatté avec [`black`](https://black.readthedocs.io/) avant
 tout commit (configurez votre éditeur pour appeler `black` à l'enregistrement).
 
 #### Documentation
+
 On pourra adopter le style "Google": <https://google.github.io/styleguide/pyguide.html#383-functions-and-methods>
 
 Exemple:
@@ -64,6 +65,7 @@ distribués (*releases*). Les développements ont lieu sur d'autres branches
 La branche `Scodoc7` était l'ancienne (jusqu'à septembre 2021) version de ScoDoc.
 
 Ci-dessous quelques pense-bête qui peuvent servir.
+
 #### Hot fixes (internes)
 
 Pour les développeurs internes (écriture sur le dépôt master), un exemple
@@ -84,13 +86,14 @@ basique illustrant le cycle de développement:
 
     # éventuellement: git stash pop
 
-Dans la plupart des cas, on travaillera sur son propre dépot (clone du dépt
+Dans la plupart des cas, on travaillera sur son propre dépôt (clone du dépt
 origine), et on proposera une *pull request* (PR, *demande d'ajout* en français).
 
 #### Mettre à jour votre branche
 
 Quand vous travaillez dans votre branche `ma_branche`, pour lui appliquer les
 mises à jour de `master` (remote), faire:
+
 ```bash
     git pull origin master
 ```
@@ -103,18 +106,19 @@ mises à jour de `master` (remote), faire:
 #### Refactoring
 
 Lint tous les fichiers modifiés:
+
 ```bash 
     git status | grep modified | grep .py | awk '{print $2}' | xargs pylint -E
 ```
-Restore les modes au besoin (SAMBA les changent parfois):    
+
-```bash    
-    git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply
-```
 Affiche les variables non définies dans un fichier:
+
 ```bash
    pylint --disable=all  -e E sco_parcours_dut.py | grep undefined-variable | awk '{print $4;}' | sort | uniq | tr -d \' 
 ```
+
 Prépare un sed pour renommer les variables non définies:
+
 ```bash
    for f in *.py
    do
@@ -122,6 +126,13 @@ Prépare un sed pour renommer les variables non définies:
    done
 ```
 
+Restore les modes au besoin (SAMBA les changent parfois):
+
+```bash    
+    git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply
+```
+
+
 Note pour travailler sur VirtualBox:
 
     addgroup scodoc vboxsf
@@ -164,10 +175,11 @@ la commande:
 
 Par la suite vous aurez donc une référence vers votre dépôt personnel (`perso`)
 et une référence vers le dépôt officiel (`officiel`). Si vous avez initialement
-cloné l'un des deux dépôts, la référence vers le dépot d'origine existe et a pour nom
+cloné l'un des deux dépôts, la référence vers le dépôt d'origine existe et a pour nom
 `origin`.
 
 La commande vous exposant tous les dépôts connus est :
+
 ```bash
   git remote -v
 ```
@@ -184,6 +196,7 @@ modifications en cours, encadrez les lignes suivantes par `git stash` (avant) et
   git reset --hard officiel/master
   git checkout -b ma_modif 
 ```
+
 À partir de là, vous pouvez modifier, tester, développer et commit votre travail.
 
 #### Suivi
@@ -207,7 +220,9 @@ Les commandes git correspondantes :
   git fetch officiel
   git merge officiel/master
 ```
+
 ou
+
 ```bash
   git fetch officiel
   git rebase officiel/merge
@@ -243,18 +258,20 @@ l'équivalent sous *pyCharm*).
 Faire une première lecture rapide pour vérifier qu'il ne reste pas de fichiers
 modifiés accidentellement.
 
-Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par exemple)
+Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par
+exemple):
+
 ```bash
   git diff officiel/master app/fichier.py
 ```
 
 Utilisateurs Windows : Vérifiez bien que les réglages de fin de ligne suivent
-bien les règles Linux (pas de retour chariot (noté CR ou `\r`) en fin de ligne mais un seul caractère line feed 
+bien les règles Linux (pas de retour chariot (noté CR ou `\r`) en fin de ligne
-(noté LF  ou `\n`). 
+mais un seul caractère line feed (noté LF  ou `\n`). Le cas échéant, réglez
-Le cas échéant, réglez votre IDE pour cela.
+votre IDE pour cela.
 
-À ce niveau là de la procèdure, vous n'avez plus dans votre branche locale que les différences strictement
+À ce niveau là de la procédure, vous n'avez plus dans votre branche locale que
-nécessaires à votre correctif.
+les différences strictement nécessaires à votre correctif.
 
 ##### Étape 3 : résumez tous les commits depuis le point de divergence en un seul commit
 
@@ -267,17 +284,20 @@ Demander un `rebase` interactif depuis ce point :
   git rebase -i $(git merge-base HEAD officiel/master)
 ```
 
-*Explications*:
+*Explications*: Le rebase interactif permet d'enregistrer un suite de
-_Le rebase interactif permet d'enregistrer un suite de manipulation de commit dans un seul fichier texte._ 
+manipulation de commit dans un seul fichier texte. Le fichier texte qui reprend
-_Le fichier texte qui reprend tels quels tous les commits concernés (et donc qui ne fait rien)_ 
+tels quels tous les commits concernés (et donc qui ne fait rien) est préparé par
-_est préparé par la commande `-i` de la commande_ `git rebase`
+la commande `-i` de la commande_ `git rebase`.
 
-_Vous pouvez ensuite modifier ce fichier dans votre editeur favori (ou pas) (à régler par `git config`) pour décrire_
+Vous pouvez ensuite modifier ce fichier dans votre éditeur favori (ou pas) (à
-_votre intention (réordonner, changer le message, fusionner, ...) sur l'ensemble des commits_
+régler par `git config`) pour décrire_ _votre intention (réordonner, changer le
+message, fusionner, ...) sur l'ensemble des commits.
+
+Quand votre édition est terminée, git reprend la main est exécute chacune de vos
+opérations. Il est possible (bien que très rare) que des conflits apparaissent
+à ce moment-là. Les commandes habituelles de correction accompagnées des
+commandes :
 
-_Quand votre édition est terminée, git reprend la main est exécute chacune de vos opérations. Il est possible_
-_(bien que très rare) que des conflits apparaissent à ce moment-là. Les_
-_commandes habituelles de correction accompagnées des commandes :_
 ```bash
 git rebase --continue # pour poursuivre le processus
 git rebase --abort # pour tout abandonner
@@ -289,6 +309,7 @@ Application:
 ```bash
 git rebase -i $(git merge-base HEAD officiel/master)
 ```
+
 Vous devez obtenir dans un éditeur de texte la liste des commits opéré depuis le
 début du développement sous cette forme (c'est un exemple : le nombre de lignes
 peut varier) :
@@ -333,6 +354,7 @@ toutes les lignes avec la première en remplaçant le 'pick' à partir de la lig
 (commande `reword` sur la première ligne).
 
 Vous construirez par exemple :
+
 ```bash
 reword eb8cbec Correctif: Api - gestion des formation
 fixup 83eb79e modif 2
@@ -349,6 +371,7 @@ Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées.
   signifiantes.
 
 ##### Étape 4 :
+
 Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel
 (vers une branche de même nom):
 
@@ -368,8 +391,9 @@ assurez-vous avant d'être le seul à travailler sur cette branche.
 * Placez-vous sur la branche nouvellement créée
 
 * À l'aide de l'interface du serveur, vous pouvez comparer l'état de votre
-  branche par rapport au master officiel, et si cela vous convient, il vous reste à formuler
+  branche par rapport au master officiel, et si cela vous convient, il vous
-  une demande d'intégration (*pull request*). En remplissant les informations demandées.
+  reste à formuler une demande d'intégration (*pull request*). En remplissant
+  les informations demandées.
 
 ## Tests et tests unitaires
 
@@ -396,9 +420,10 @@ Au besoin, mémo:
 ## Re-création du virtualenv
 
 ScoDoc est livré avec un "virtualenv", qui contient tous les modules python
-nécessaires. Il se trouve sous `/opt:scodoc/venv`.
+nécessaires. Il se trouve sous `/opt/scodoc/venv`.
 Si vous souhaitez repartir de zéro, tester de nouvelles versions de certaines
 bibliothèques, ou autres expériences de ce genre, vous pouvez le récréer ainsi:
+
 ```bash
   # en tant qu'utilisateur scodoc
   cd /opt/scodoc
@@ -407,17 +432,23 @@ bibliothèques, ou autres expériences de ce genre, vous pouvez le récréer ain
   source venv/bin/activate
   pip install wheel
 ```
+
 Puis soit vous installez les versions "officielles" (testées)
+
 ```
   pip install -r requirements-3.9.txt 
 ```
-Soit vous prenez les version les plus à jour disponibles. Une façon rapide de
+
+Soit vous prenez les versions les plus à jour disponibles. Une façon rapide de
 faire ceci est:
+
 ```bash
   cut -d= -f 1 requirements-3.9.txt | xargs pip install
 ```
 à adapter selon vos objectifs.
+
 Pour régénérer le fichier indiquant la liste des paquets:
+
 ```bash
   pip freeze > requirements-3.9.txt
 ```