Legilibre / Archeo-Lex

Pure Histoire de la Loi française – Git + Markdown
https://archeo-lex.fr
Do What The F*ck You Want To Public License
98 stars 17 forks source link

Utiliser legi.py comme base de données #31

Closed Seb35 closed 7 years ago

Seb35 commented 7 years ago

Comme discuté dans https://github.com/Legilibre/salon/issues/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 https://github.com/Legilibre/salon/issues/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 commented 7 years ago

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

Changaco commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

./archeo-lex -t LEGITEXT000006070666 --exporterlegi
Seb35 commented 7 years ago

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 commented 7 years ago

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

Seb35 commented 7 years ago

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 commented 7 years ago

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

fgallaire commented 7 years ago

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

Seb35 commented 7 years ago

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 commented 7 years ago

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 :

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.