Utiliser legi.py comme base de données

[Seb35]

Comme discuté dans Legilibre/salon#2, Archéo Lex et legi.py ont une structure très similaire de schéma de base de données (SQLite pour les deux). Il serait intéressant que legi.py devienne la base de données utilisée par Archéo Lex afin d’éviter de dupliquer les efforts, et accessoirement mutualiser les ressources sur un serveur commun (cf Legilibre/salon#8).

Plutôt que de commencer à développer ça dans une branche Git, je propose de créer une feature toggle dans la branche master => un switch à activer d’abord volontairement en CLI, puis lorsque ça sera suffisamment stable inverser sa valeur par défaut, et enfin supprimer ce switch.

[fgallaire]

Il faudrait vraiment choisir une licence commune pour ces deux projets.
Legilibre/salon#4

[Changaco]

J'ai commencé à travailler dans legi.py sur une nouvelle fonction qui yield tous les éléments des différentes versions d'un texte dans l'ordre.

[Seb35]

Bon, j’y arrive. Ça marche sur un petit code comme le code des instruments monétaires et des médailles (14 versions) strictement similaire au rendu avec ma base de données (à part un détail, je m’était planté dans le markdown au niveau du nombre de # pour les articles).

Je suis en train de faire tourner un code de taille moyenne (code de la propriété intellectuelle).

[Seb35]

Sur le CPI, j’ai surtout des problèmes sur le Markdown, où il y a plein de
au début des lignes alors que je ne les avait pas avant, ainsi que des

. J’attribue cette différence au fait que je lisais le XML avec BeautifulSoup alors que legi.py utilise lxml ; j’imagine que BeautifulSoup faisait un certain traitement du HTML embarqué dans le XML que ne fait pas lxml.

[Seb35]

En fait pour le CIMM, j’utilisais le Markdown créé avec BeautifulSoup (qui lit directement les fichiers XML), donc la phase d’export est bien strictement similaire, c’est la phase de conversion qui est différente. Bien sûr je pourrais continuer avec cette ancienne version, mais le but à terme de ne plus avoir à décompresser les tarballs, donc utiliser le texte de la base legi.py.

[Seb35]

Au niveau vitesse d’exécution, c’est similaire (= long). #32 reste valable et permettra d’améliorer ça, mais ça demande du travail.

[Seb35]

Et j’ai poussé ma version actuelle, c’est dans la branche master. Ça s’utilise avec :

./archeo-lex -t LEGITEXT000006070666 --exporterlegi

[Seb35]

Au lieu de réinventer la roue sur la conversion HTML → Markdown, j’ai cherché une bibliothèque et ai trouvé https://github.com/Alir3z4/html2text/ (paquet pypi html2text) qui fait du meilleur travail que ce je faisait sur le CIMM, notamment l’article 39. Mais en même temps ce code n’est pas très compliqué, il faudrait lui donner des listes et des tableaux.

[fgallaire]

html2text est sous licence GPL, donc si tu veux l'utiliser tu dois changer de licence.

[Seb35]

Sur la markdownisation, l’utilisation de la bibliothèque a amélioré la situation, mais il reste des détails, notamment beaucoup (trop) de lignes blanches et un problème d’alinéa sur le L121-6 du CPI (en fait ni la version actuelle ni la nouvelle n’est correcte sur cet article). Ce problème de markdownisation est en grande partie lié au mauvais HTML fourni par LEGI, avec une soupe de <br/> et parfois de <p> probablement issus d’un mauvais éditeur de texte lors de la saisie (« 2 "Entrée" = 1 nouvel alinéa »). En tous cas ce problème est indépendant de legi.py, je vais créer un bug indépendant, et mettre sous test cette fonction.

[Seb35]

@fgallaire Je l’utilise comme bibliothèque, je ne l’inclue pas dans le code.

[fgallaire]

@Seb35 ça ne change rien.
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL

[Seb35]

J’ai regardé aussi, il y a stricte-viralité comme ton lien ou certaines réponses dans la FAQ FSF GNU, et des moins-catégoriques-sur-la-stricte-viralité comme http://opensource.stackexchange.com/questions/2666/picking-a-license-for-library. http://opensource.stackexchange.com/questions/2139/can-i-license-python-project-under-3-clause-bsd-while-it-has-gpl-based-dependenc dit qu’il faut plus rentrer dans le détail, ce que fait aussi la FAQ FSF GNU. Les détails en question sont : la distribution d’un binaire/code objet vs du code source, la plus ou moins grande intégration (bibliothèque vs plug-in), la licence des fichiers vs la licence du logiciel (en tant qu’auteur des fichiers, je peux les mettre comme je veux, mais si je distribue un binaire, le binaire doit être GPL).

Tu peux ouvrir une issue plutôt qu’on continue à en discuter dans celle-ci ? D’autant que ça n’est pas spécifique à html2text, mais à toutes les bibliothèques utilisées.

Pour html2text, je vais voir si je peux ne pas l’utiliser finalement. À moins que ça n’apporte un gain énorme, je vais voir si juste changer les <br/><br/> en lignes blanches peut suffire.

[Seb35]

Le CPI passe désormais bien, je n’ai finalement pas utilisé html2text mais ai comparé le résultat attendu par Légifrance et celui donné par le XML-HTML. Basiquement, j’ai déployé les <p>(.*?)</p> en paragraphes Markdown, transformé les <br ?\/> en retour à la ligne simple (il faut faire attention à ne pas faire de doubles retours à la ligne), puis dans un second temps retiré les trop grands retours à la ligne '\n\n+' → '\n\n' et enfin retiré les espaces orphelines en début et fin de lignes.

C’est poussé/pushé. Le résultat pour le CPI est sur https://archeo-lex.fr/codes/code-de-la-propriété-intellectuelle et j’ai laissé temporairement l’ancien résultat sur https://archeo-lex.fr/codes/code-de-la-propriété-intellectuelle-(archive-Archéo-Lex).

Entre autres améliorations venant avec ce changement :

• certains articles manquaient (Manquement de paragraphes dû aux versionnage de sections #11) ou étaient placés au mauvais endroit (ordre d’affichage non-respecté, c’était forcément sous-sections puis articles) et cela semble au moins en partie résolu : dans le CPI la sous-section "Annexe de l’article R321-8" était placée en début de la section parente alors qu’elle aurait dû être placée juste après l’article R321-8, je regarderai si c’était la même chose sur Manquement de paragraphes dû aux versionnage de sections #11
• les tableaux sont désormais affichés en HTML (c’est pas joli à voir en Markdown mais ça s’affiche) alors qu’ils était auparavant brisés (seul le texte restait, la structure tableau était retiré, donc le sens largement perdu), cf par exemple dans le CPI version 3 mars 2004 les annexes à l’article R321-8 (il manque les traits du tableau sur le site archeo-lex mais la structure est correcte, et ça semble casser le rendu Markdown → HTML après ces articles, probablement un problème de JavaScript)
• les alinéas sont de bien meilleure qualité, cf par exemple l’article L122-10, la modification de l’alinéa le 24 décembre 2016 se retrouve bien sur Légifrance https://archeo-lex.fr/codes/code-de-la-propriété-intellectuelle.git/commit/ffec1b3d3c911564333b1446fbb73a5814f2793f#L22R522

En résumé, ça a demandé du travail, mais ça a fait faire un bond dans la qualité du rendu. Merci @Changaco pour legi.py.