Faire tourner Archéo Lex sur tous les codes avec une base LEGI récente

[Seb35]

C’était à faire depuis quelques temps et Suzanne Vergnolle m’a d’ailleurs relancé il y a une dizaine des jours.

Ce bug est un bug de tracking, il sert à résumer l’avancement et à faire le point sur les différents problèmes que pourrait rencontrer un utilisateur qui débuterait avec Archéo Lex. Ce bug sera fermé lorsque tous les codes tourneront correctement. L’automatisation éventuelle est hors de portée de ce bug et doit faire l’objet d’un bug séparé.

[Seb35]

À date :

• j’ai donc téléchargé la dernière version de la base LEGI (20160406-082840 puisque c’est la plus récente) et les mises à jour incrémentales,
• accepté 3 pull requests de @tianyikillua et fait quelques commits pour corriger des problèmes liés au téléchargement de la base LEGI,
• j’ai essayé de versionner sous Git les 1,5M de fichiers et 1,5M de dossiers de la base LEGI, ça n’était probablement pas une idée intéressante, ça a mis plusieurs dizaines d’heures pour enregistrer (git add + git commit) et plusieurs dizaines d’heures pour compresser (git gc, pour créer des packs et réduire drastiquement le nombre de fichiers/inodes dûs à git, passant de 3M à 36 pour 2,2Gio) ; à cette vitesse il vaut mieux décompresser les différents .tar.gz ;
• je prépare un commit pour supprimer les fichiers à supprimer dans les mises à jour incrémentales de la base LEGI.
  Je pense être bientôt (1 semaine) prêt à faire tourner en production, déjà pour atteindre la version actuelle de la base LEGI (environ 200 màj incrémentales à appliquer), ensuite pour remplir la base de données et enfin pour exporter au format git.

[Seb35]

Je mentionne ici une idée pour ne pas oublier, mais ça pourra probablement faire l’objet d’un bug séparé.

Avec mes déboires de versionnement sous Git des fichiers de la base LEGI et en parallèle en étudiant les tréfonds de Docker, notamment le système de fichiers AuFS, je me dis que ça pourrait être intéressant de voir les fichiers de la base LEGI comme une superposition de couches, donc de décompresser la version initiale dans un répertoire puis chaque màj chacune dans des répertoires propres (à voir comment gérer les suppressions de fichiers).

Ensuite, à la lecture, pour lire un répertoire spécifique :

• on lit la 1re couche (màj incrémentale la plus récente),
  • si on trouve le fichier : ok
  • sinon la 2e couche -> récursion/boucle for

En comparaison de l’algorithme « on décompresse la base LEGI jusqu’au jour J », l’avantage est d’avoir de pouvoir lire en même temps toutes les livraisons de la base LEGI. En inconvénient, cet algorithme est plus lent à la lecture. Il est aussi possible de mélanger les deux stratégies et de combiner ça avec la gestion de l’espace disque :

• si espace disque faible : stratégie classique, donc abandon de pouvoir naviguer entre les livraisons,
• si espace disque important : cette stratégie, avec compilation de la base LEGI entière à certaines dates (par exemple tous les 3 mois)

Dans le même ordre d’idée, peut-être que les systèmes de fichiers avec la fonctionnalité de snapshot pourraient être intéressants (par exemple btrfs ou zfs, cf comparaison des systèmes de fichiers). Je n’ai jamais utilisé ce type de fonctionnalité, mais ça peut valoir le coup de s’y pencher.

[fenollp]

Note que la plupart des hebergeurs Git gratuits (bitbucket, gitlab, github) limite les .git a 1GB et au dela suppriment des fichiers au hasard.

Autre solution a envisager: stocker des tarball dans https://git-lfs.github.com/

[Changaco]

Je ne comprends pas pourquoi tu persistes à vouloir extraire les archives, ça ne fait que gâcher de l'espace disque et du temps.

Je reste aussi sceptique sur l'export vers Git, d'autres projets l'ont déjà fait, et quitte à utiliser un logiciel existant MediaWiki est bien plus puissant que la meilleure des interfaces web Git.

[fenollp]

Autre solution: subdiviser les donnees pour les stocker dans plusieurs repo. Pourquoi pas en faire un autre qui les ajoute tous en submodules.

[Seb35]

@fenollp La place n’est un problème que pour la base LEGI originale (~10 Gio lorsque décompressée). Après extraction avec Git, les dépôts ne font que quelques centaines de Kio après compression (git gc), par exemple les 4 que je viens de terminer (pas encore publiés) :

• 664K codes.git/code-civil.git
• 536K codes.git/code-de-la-propriété-intellectuelle.git
• 448K codes.git/code-de-l’entrée-et-du-séjour-des-étrangers-et-du-droit-d’asile.git
• 396K codes.git/code-pénal.git

Ils font effectivement jusqu’à une centaine de Mio avant compression mais vu que l’étape de compression ne prend que 15-30s, il ne faut pas s’en priver. Au passage, ce niveau de compression important montre le degré de modification au final très faible dans les historiques.

Avant compression :

• 72M codes/code-civil/.git
• 48M odes/code-de-la-propriété-intellectuelle/.git
• 30M codes/code-de-l’entrée-et-du-séjour-des-étrangers-et-du-droit-d’asile/.git
• 39M codes/code-pénal/.git

[Seb35]

@Changaco Sur ma volonté de prendre en compte les archives, c’est parce que je préfère pouvoir recalculer des choses après coup et avoir des résultats reproductibles. Étant donné la rigueur du format Git (changer un caractère change le numéro de commit de la version en cours et de toutes les versions à la suite), je préfère pouvoir suivre assez finement les changements. Par exemple, si la mise en page est changée dans un article lors d’une livraison, je peux :

1. soit intégrer cette modification dans la prochaine version du code, mais ça n’est pas satisfaisant car cette modification n’est pas dû à cette nouvelle version mais provient d’un effet de bord entre différentes livraisons de la base LEGI
2. soit je réécris effectivement l’historique en repartant de la date où a été introduit l’article, et il me semble que j’ai besoin comparer l’historique de l’ancienne et nouvelle livraisons (si c’est dans la base de données + dans le cache Markdown, je pense ne pas avoir besoin de la base LEGI)

Sur l’existance de ce cas, je me suis longtemps demandé si ça valait le coup de le prendre en compte, et je suis tombé une fois sur une délibération CNIL (pas la base LEGI mais similaire donc) où il avait été un jour publié la délibération, puis dans une livraison ultérieure la même délibération mais anonymisée. Donc la réécriture existe, et je pense que le cas ne peux pas être évité, il peut toujours y avoir des erreurs (sur le texte lui-même) qui sont corrigées lors de livraisons suivantes.

Je précise que le comportement actuel est le premier scénario car l’implémentation actuelle est trop simpliste, mais c’est à mon sens un bug et il serait souhaitable de basculer vers le deuxième scénario (à moins d’une autre solution).

Après, sur la gestion en pratique de la base LEGI et pour des questions de performance comme expliqué dans mon commentaire, je reviens sur mon idée d’archiver sous Git la base LEGI car il est effectivement beaucoup plus performant de réextraire les .tar.gz. Il est possible aussi que le scénario "AuFS" soit également peu performant, mais pour l’instant je n’en sais rien.

[Seb35]

@Changaco Sur le versionnement Git ou MediaWiki, ça rejoint le « est-ce mieux d’avoir tout dans un fichier unique ou dans une arborscence ? », c’est-à-dire qu’il est possible d’extraire au format qu’on veut.

Il faut soit se mettre d’accord – c’était l’approche un peu testée depuis deux ans entre les quelques projets similaire – soit accepter qu’il n’y a pas une réponse unique, mais que cela varie en fonction des besoins et des préférences. Je m’oriente vers cette deuxième voie (cf par exemple #18 visant à rajouter des liens internes : c’est utile pour certains usages mais pas tous, donc il faut mettre un switch et ceux qui veulent des liens activeront le switch).

Avec le temps et les usages, j’imagine que certaines versions seront plus utilisées, par exemple une « Git + Markdown + fichier unique », une « Git + Markdown + arborscence » et une « MediaWiki + wikitexte + fichier unique ». Chacune aura ses avantages, ses inconvénients, et son utilité vis-à-vis d’un besoin spécifique.

En résumé, pull requests acceptées pour des variantes dès qu’elle peuvent être sélectionnées via un switch.

[Changaco]

Quand je dis "extraire les archives" je parle de faire un tar -xf archive.tar.gz ou équivalent. C'est un gâchis de ressources, legi.py ne le fait jamais, il transforme les archives directement en base SQLite sans passer par une extraction intermédiaire dans un système de fichier.

Détecter les corrections des contenus ou de leurs mises en page ne nécessite pas de conserver les anciennes versions.

[fgallaire]

@Changaco je ne suis pas sûr de comprendre ce qe tu veux dire, mais utiliser MediaWiki "à la place de Git" est une hérésie technique : base SQL contenant toutes les versions avec des diffs en PHP.

[Changaco]

Le fait que Git ne puisse pas modifier un ancien commit sans modifier tous les suivants est une des raisons qui font qu'à mon avis il n'est pas un bon format d'export pour les bases de données juridiques.

Si le but est de pouvoir explorer les textes et les différences entre versions alors MediaWiki est meilleur que Git. Si le but est d'exploiter les données d'une autre manière alors il vaut mieux utiliser directement la base SQLite. Bref, je ne vois pas dans quel cas passer par Git est bénéfique.

[fgallaire]

Je cherche à comprendre ton argument, quel est le cas pratique pour une bd juridique de modifier un ancien commit ?

Pour les diffs : Git, dont c'est l'unique utilité, est très largement supérieur à 2 requêtes MySQL + un diff calculé en ugly PHP.

[Changaco]

La nécessité de pouvoir corriger un ancien commit a été expliquée tout à l'heure par @Seb35.

Un diff n'est pas une opération très coûteuse, l'implémentation de MediaWiki est probablement bien suffisante. (Par ailleurs je ne suis pas convaincu que Git soit plus efficace pour calculer un diff entre deux versions non-adjacentes, car il doit d'abord reconstruire l'ancienne version, mais bon on s'éloigne du sujet.)

[Seb35]

@fgallaire @Changaco Cas existants de modifications que j’ai recensé :

• comme dit plus haut, l’anonymisation d’une délibération CNIL (je n’ai pas conservé la référence)
• la suppression d’une espace "Art.L. 4424-40" -> "Art. L. 4424-40" (LEGITEXT000006074073/LEGIARTI000006812746 entre les versions 20140718-113010 et 20150107-144552)
• sur le code du tourisme, j’ai trouvé des dates d’entrée en vigueur qui avaient été changé entre les livraisons 2014-07-18 11:30:10 et 2015-01-07 14:45:52, voici les extraits de la base de données (la structure a un peu changé entre les deux mais on retrouve les données). Je l’interprète (à vérifier) comme le fait qu’une entrée en vigueur future a été modifiée entre temps par une autre loi.

sqlite> select * from article where num='L161-1'; // Version 2014-07-18 11:30:10
LEGIARTI000006812757||MODIFIE|L161-1|2005-01-01|2010-06-30|LEGITEXT000006074073|LEGISCTA000006143158|1
LEGIARTI000022405438||MODIFIE|L161-1|2010-06-30|2014-04-01|LEGITEXT000006074073|LEGISCTA000006143158|1
LEGIARTI000025387980||VIGUEUR|L161-1|2014-04-01||LEGITEXT000006074073|LEGISCTA000006143158|1

sqlite> select * from version_article where nom='L161-1'; // Version 2015-01-07 14:45:52
LEGIARTI000025387980||L161-1|VIGUEUR_DIFF|3|2222-02-22||975a0|LEGITEXT000006074073
LEGIARTI000022405438||L161-1|ABROGE_DIFF|2|2010-06-30|2222-02-22|cb500|LEGITEXT000006074073
LEGIARTI000006812757||L161-1|MODIFIE|1|2005-01-01|2010-06-30|f61a0|LEGITEXT000006074073

Il n’y a pas « d’utilité » à changer la base de données, juste qu’il y a des modifications « éditoriales », qu’il gérer pour bien faire les choses.

[Changaco]

(Je rappelle qu'un des sens du nom "Git" est "stupide", et que ce n'est pas un hasard. C'est loin d'être un gestionnaire de version idéal même s'il est beaucoup mieux que ceux qui l'ont précédé. Pour le futur il y a le projet Pijul qui est potentiellement prometteur.)

[Seb35]

Sur les histoires de stockage, Git comme MediaWiki stockent les textes entiers (cf Git internal), et tous les deux recréent les diffs à la volée. Bien sûr, les deux utilisent la compression, soit en interne pour Git, soit via MySQL pour MediaWiki.

Si on compare les deux :

• Git est un format de stockage, alors que MediaWiki s’appuie sur une base de données externe, donc en ce sens Git est plus portable (si vous allez voir sur mon wiki, j’ai un prototype d’export d’un historique MediaWiki vers Git, notamment pour de la portabilité + offline).
• Git a l’avantage d’avoir des identifiants stables, ce qui est aussi un inconvénient.
• Sur la réécriture d’historique, Git peut avoir des branches ; sur MediaWiki, il faut supprimer certaines versions puis remettre les nouvelles versions (et les identiants (paramètre "oldid") vont changer).
• Sur les diffs, chacun a son moteur de diffs, plus ou moins « bon » ; personnellement je ne suis pleinement satisfait par aucun des deux, je trouve qu’il y aurait moyen d’améliorer ce point, et ce point peut dans l’absolu être indépendant : on peut faire un meilleur moteur de diffs qu’on donnerait à Git et à MediaWiki.

Après, chacun a ses finalités, ses cas d’usage, etc. donc on peut tout à fait préférer l’un ou l’autre, et trouver qu’un usage est meilleur sur l’une ou l’autre plateforme.

[Changaco]

C'est vrai que MediaWiki a aussi des limites (par exemple je ne crois pas qu'il sache faire un diff sur plusieurs pages en même temps, or on ne peut pas mettre tout un Code dans une seule page). Je ne dis pas que c'est l'outil parfait, juste que dans ceux existants il me semble être meilleur que Git si le but est d'avoir une alternative basique à Légifrance qui permette de visualiser les différences entre versions.

Ceci dit je pense qu'il vaut mieux construire ses propres outils que d'essayer de détourner un existant jusqu'à l'absurde, donc comme MediaWiki et Git semblent tous deux inadaptés j'opterais plutôt pour des solutions maison.

[Changaco]

Sur les histoires de stockage, Git comme MediaWiki stockent les textes entiers (cf Git internal)

Le lien que tu donnes n'explique que le fonctionnement basique de Git, la vraie "magie" est dans les Git Packfiles.

[fgallaire]

https://lwn.net/Articles/131657/

[Seb35]

Cette issue est en passe d’être résolue. Plusieurs alignements sont en passe de prendre effet pour rendre cette production possible (110k textes dans la base LEGI, 45% d’arrêtés, 45% de décrets) :

• la publication automatisée sur un Gitlab est possible depuis une semaine : les textes produits sur Legitfrance flavour Framagit sont produits de façon complètement automatique (j’ai lancé Archéo Lex en lui disant de calculer des textes au hasard).
• je fais tourner sur un serveur depuis 32 jours des textes, dont la production des codes ; la bonne nouvelle est que les résultats sont très correct, la mauvaise est que ça n’a produit que 61 codes.
• cette mauvaise performance sera très fortement atténuée (ça se compte en échelle exponentielle) grâce au cache de section (Créer un cache des sections pour accélérer l’export #32) d’une part (un code de taille moyenne comme le CPI passe de quelques heures à quelques minutes après une première expérimentation) et grâce au stockage en mémoire des articles après conversion Markdown d’autre part plutôt que sur des fichiers sur disque (ceci dans la restructuration+abstraction de Archéo Lex)
• afin d’éviter de faire supporter à Framagit la gestion de 110k textes, nous avons mis en place hier avec Emmanuel un Gitlab dédié, il faut encore gérer le lancement automatique de VMs chez Online (+destruction), cela peut se faire en finalisant le container Docker commencé avec Jean-Marc et en gérant le partitionnement du domaine des 110k textes
• la mise à jour est désormais ultra-légère : legi.py ne fait qu’ajouter les textes de la journée (~5 min/jour) et AL ne fait désormais que re-calculer les versions à partir de la plus vieille version modifiée (auparavant cette notion de mise à jour n’existait pas, il n’y avait que des initialisations) (~15 min/jour ?), et AL sera aussi beaucoup plus rapide avec le cache de sections et l’utilisation de la mémoire vive. Le processus de mise à jour ne devrait donc prendre que quelques minutes par jour. J’ai testé ce processus de façon expérimentale, il faudra vérifier en production.

[fenollp]

La version gratuite et hosted de gitlab donne 2000 minutes de CI par mois, un cron et un cache. Pourquoi partir sur une solution qui nécessite de provisionner des VM, de payer le service et de faire du Ops ?
En plus, avoir une conf de CI publique permet à tout un chacun de comprendre et reproduire la compilation des codes.

[Seb35]

Je crois pas trop aux trucs magiques "qui marchent tout seuls", il faut de toutes façons toujours faire de la config et des scripts. Pour l’instant, on est parti là-dessus parce qu’il faut avancer ; si tu veux proposer des PR pour des déploiements CI ou ailleurs, n’hésites pas.

[Seb35]

Résolu à 99,05 % = 104/105, tous les codes tournent quotidiennement depuis une semaine sur https://archeo-lex.fr et fonctionnent à part le code des communes (ça se voit pas sur l’interface web, mais lors de la màj 14/09 -> 19/10 il était en erreur, j’avais fait en sorte que ça affiche l’erreur, mais du fait qu’il n’a pas été mis à jour depuis le 19/10 l’erreur a été effacée).

[Seb35]

Bon, c’est résolu à 100 %. Tous les codes sont disponibles quotidiennement sur https://archeo-lex.fr.