Créer un format “un répertoire par article”

[Seb35]

Au lieu d’avoir tout un code dans un seul fichier texte, créer deux formats basés sur des répertoires :

1. des répertoires plats (flat) à raison d’un répertoire par article : /L111-1, /L111-2, /L112-1, etc.
2. des répertoires hiérarchisés par la section à laquelle ils appartiennent : /Livre Ier/Titre Ier/Chapitre Ier/L111-1, /Livre Ier/Titre Ier/Chapitre Ier/L111-2, /Livre Ier/Titre Ier/Chapitre II/L112-1, etc.

Pour le 2e format, je n’ai indiqué ici que la numérotation des sections mais il faudrait probablement y rajouter le nom de la section, sinon celui-ci n’apparaîtrait nulle part alors qu’il a son importance. Perser également à l’ordre alphabétique des répertoires utilisé par défaut par les systèmes de fichiers : par exemple un article /D111-1 se trouverait avant un article L111-1, de même des problèmes pour la numérotation romaine (c, d, i, ii, iii, iv, ix, v, vi, vii, viii, x). Réfléchir donc aux différents choix et en choisir un ou plusieurs qui seraient judicieux.

Ce type d’organisation serait beaucoup plus facile à exploiter par une machine, car plus structuré que l’actuel format d’un fichier texte qu’il faudrait parser.

On notera que lorsque la structure des sections change, et notamment le renommage, cela aurait pour effet de créer un déplacement de répertoire, ce qui n’est pas extraordinairement bien géré par Git, mais il n’y a pas le choix.

[RouxRC]

Respecter l'ordre alphanumérique avec les noms de dossier est malheureusement vraiment compliqué à assurer. Plusieurs idées différentes avaient été explorées ici https://pad.lqdn.fr/p/gitlaw La plupart reposaient sur le nom préfixé par quelque chose de peu intelligible, ou risquaient de rater des cas particuliers. Une solution de repli consisterait à insérer à la racine de chaque dossier de section un fichier de type "order" listant chaque sous élément dans l'ordre à raison d'un par ligne par exemple.

[Seb35]

J’avais effectivement souvenir que ça avait été discuté, merci du résumé et du pad.

Après, si on veut créer ce type de sortie pour des machines uniquement en s’affranchissant de la contrainte "lisible par un humain", ce type de question est grandement simplifié.

Dans l’immédiat, ce type de sortie serait pour effectivement faire réutiliser le résultat par une machine, cf le projet esquissé sur https://github.com/Legilibre/salon/issues/6#issuecomment-277523738.

[Seb35]

Dans la restructuration en cours du code, j’abstrais (entre autres) ce type d’organisation, étant donné que j’ai pris mon parti qu’on ne trouvera pas un unique format qui conviendrait à tout le monde mais qu’il faut être flexible pour s’adapter aux besoin des réutilisateurs.

La restructuration en cours sont les fichiers FabriqueArticle.py, FabriqueSection.py et le dossier exports où j’ai fait une "interface" Organisations (j’ai l’impression que ça n’est pas l’habitude dans le monde Python, mais ça m’aide à structurer et documenter le code). Cette structure a besoin d’une autre interface Syntaxes qui représente la syntaxe du texte (actuellement Markdown uniquement). Actuellement, il y a deux implémentations de cette interface Organisations :

• FichierUnique : tout le texte dans un même fichier, la forme historique de Archéo Lex (et celle que je préfère pour ma part en tant qu’humain)
• UnArticleParFichierSansHierarchie : un fichier par article, chacun nommé avec la forme "Article_L35-1.md", rangé à la racine du repository sans arborescence. Ce format est utilisé par [Amenda]().

Le format proposé dans cette issue pourrait être implémenté, ou pas, selon les demandes, ou en test bonus pour s’amuser. En revanche, si un réutilisateur veut un format spécifique, il suffit de proposer une pull request et je l’accepterai sans problème (tant que c’est bien écrit). Je laisse cette issue ouverte mais il n’est pas sûr que je la résolve, éventuellement je la fermerai.

[Seb35]

Cette issue est fonctionnelle depuis longtemps pour les organisations /article1.md, /article2.md, et avec la réorganisation que je viens de (quasiment) terminer, le code est suffisamment clair. Je viens de créer (assez facilement) l’organisation /chapitre1/section1/article1.md, /chapitre1/section1/article2.md. Les trois organisations actuellement possibles sont :

• --organisation=texte (par défaut), la version historique "tout le texte dans un fichier", classe FichierUnique
• --organisation=articles (pour DuraLex), version "un article par fichier, à plat, sans hiérarchie", classe UnArticleParFichierSansHierarchie
• --organisation=sections, version "un article par fichier, avec la hiérarchie des sections", classe UnArticleParFichierAvecHierarchie

Pour ajouter une organisation de fichiers (au moins une organisation qui agit sur les articles, même si une organisation qui agit au niveau des sections devrait aussi fonctionner), il faut recopier un de ces fichiers et, dans la fonction obtenir_nom_fichier, renvoyer une string lorsqu’on veut enregistrer le contenu sous-jacent, avec le nom du fichier tel qu’on le souhaite (le paramètre parent est utile pour savoir où on se situe dans la hiérarchie des sections).