Ajouter des switchs pour sélectionner la forme du texte exporté

[Seb35]

La forme originelle des dépôts Git créés par Archéo Lex est bien spécifique et ne convient pas à tout le monde ou pour différents usages. Par exemple j’ai fait le choix de mettre tout le code sur une page, d’autres comme @steeve ont fait le choix de créer des sous-dossiers, il y a des issues ouvertes pour rajouter des hyperliens (#2) ou un sommaire (#19), on pourrait vouloire d’autres dialectes comme du Markdown GitHub ou du wikitexte ou du RestructuredText. Et cætera.

Certaines formes sont plus adaptées à certains usages :

• lecture du texte par un humain ou recherche plein texte dans un code : besoin d’un texte le plus simple possible sans balisage qui gênerait la lecture ou renverait des faux positifs pour la recherche plein texte → Markdown sans hyperliens ;
• texte enrichi de métadonnées : par exemple avec des hyperliens, un sommaire, les noms des parlementaires à l’origine de l’amendement → HTML ou Markdown avec hyperliens et autre balisage spécifique, notamment en vue de créer du HTML
• format structuré lisible par une machine : organisation complètement prévisible et facilement navigable pour une machine → XML, JSON, YAML, ou plein texte dans des sous-répertoires

À côté de ces légitimes cas d’utilisation s’oppose la rigidité du format Git : toute modification, la plus infime soit-elle, entraîne la réécriture de l’historique entier, alors que certains réutilisateurs seraient naturellement intéressés pour utiliser l’historique Git comme source d’identifiants pérennes.

Pour prendre en compte ces deux contraintes opposées, je propose de créer dans Archéo Lex un switch qui permettrait lors de l’export de choisir la forme précise du texte. Un réutilisateur pourrait alors choisir cette forme et soit ne jamais plus en changer soit accepter de perdre la pérénnité des identifiants de commits (là-dessus, je ne peux rien faire, si ça ne convient pas il faut utiliser un autre format).

[Seb35]

En fait il faudrait plusiers switchs vu le nombre de combinaisons. Pour des questions d’utilisabilité de l’interface CLI, il faudrait tout de même qu’ils aient des noms similaires, par exemple --format-avec-sommaire / --format-sans-sommaire, --format-avec-hyperliens / --format-sans-hyperliens, --format-dialecte markdown / --format-dialecte gfm (GitHub Flavored Markdown) / --format-dialecte rst (RestructuredText).

[Seb35]

En fait quelques options étaient déjà présentes mais inutilisées par le programme, j’ai donc juste un peu clarifié l’aide en ligne de commande pour bien isoler ces options liées au format d’export et dans le code les ai regroupé dans un unique dictionnaire définissant le “format”.

J’ai laissé les options CLI existantes, sans changer leur nom par rapport à ce que je proposais dans le commentaire précédent, surtout pour éviter les noms à rallonge. N’hésitez pas à commenter si vous penser qu’il vaut mieux une interface plus unifiée, il y a peut-être moyen de trouver une façon de faire pour unifier sans trop rallonger les noms des options.