New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Seb35 opened this Issue Feb 27, 2017 · 14 comments

Comments

Projects
None yet
3 participants
@Seb35
Member

Seb35 commented Feb 27, 2017

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

This comment has been minimized.

Member

fgallaire commented Feb 28, 2017

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

@Changaco

This comment has been minimized.

Member

Changaco commented Mar 1, 2017

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

This comment has been minimized.

Member

Seb35 commented Mar 19, 2017

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

This comment has been minimized.

Member

Seb35 commented Mar 19, 2017

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

This comment has been minimized.

Member

Seb35 commented Mar 19, 2017

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

This comment has been minimized.

Member

Seb35 commented Mar 19, 2017

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

This comment has been minimized.

Member

Seb35 commented Mar 19, 2017

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

./archeo-lex -t LEGITEXT000006070666 --exporterlegi
@Seb35

This comment has been minimized.

Member

Seb35 commented Mar 19, 2017

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

This comment has been minimized.

Member

fgallaire commented Mar 20, 2017

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

@Seb35

This comment has been minimized.

Member

Seb35 commented Mar 20, 2017

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

This comment has been minimized.

Member

Seb35 commented Mar 20, 2017

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

@fgallaire

This comment has been minimized.

Member

fgallaire commented Mar 20, 2017

@Seb35

This comment has been minimized.

Member

Seb35 commented Mar 20, 2017

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

This comment has been minimized.

Member

Seb35 commented Mar 20, 2017

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 (#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 #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.

@Seb35 Seb35 closed this Mar 20, 2017

This was referenced Apr 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment