legilibre/archeo-lex

Pure Histoire de la Loi française – Git + Markdown

archeo-lex's Issues

Utilisation de initRechCodeArticle.do

L'utilisation de initRechCodeArticle.do est une erreur :

• Le parsing d'un document HTML n'offre aucune garantie
• Ces informations pourraient ne pas être cohérentes avec la base
• Ces informations sont dans la base
• Point de plantage supplémentaire (téléchargement ne marche pas chez moi)

Automatisation et calcul transparent

Histoire que

• les donnees soient a jour avec LEGI
• le calcul de ces donnees soit reproduisible par n'importe qui
• on ait a avoir a faire confiance a moins de personnes pour s'assurer que le traitement des donnees soit bien celui que le code est sense faire (i.e. pas de moderateur/censure)

Je propose qu'on mette en place une tache cron, ou un outil de Continuous Integration (integration continue).
Il en existe beaucoup de gratuits pour les projets open source.

• Travis CI a meme un service CRON
• CircleCI aussi, en plus les jobs peuvent tourner jusqu'a un maximum de 2 heures
• ...

Améliorer l’esthétique de la page d’accueil du site archeo-lex.fr

La page d’accueil du site https://archeo-lex.fr est très rudimentaire. Il faudrait la rendre un peu plus attractive d’une part et la mettre aux couleurs de Légilibre d’autre part (c’est-à-dire reprendre la trame de http://legilibre.fr et http://anomalies.legilibre.fr).

Ajouter une option pour gérer la niceness

Cas d’usage

Pendant le développement, la décompression de la base LEGI complète dure entre 5 et 10 minutes chez moi, et lorsque je fais quelque chose à côté (comme rédiger cette proposition de fonctionnalité par exemple) l’ordinateur est ralenti ; pour contrer ça et rédiger tranquillement ce bug, j’augmente la niceness (à 5, voir renice(1)) ainsi que l’ioniceness à B5 (best-effort 5, voir ionice(1)).

Proposition de fonctionnalité

Ajouter une option pour fixer la niceness.

À voir comment designer exactement l’option de la ligne de commande, peut-être (suggestion) avec une option --nice sans paramètre qui fait passer la niceness à 5 (et en conséquence l’ioniceness à B5 d’après la relation automatique) et une option --nice 10 avec paramètre pour fixer la niceness, et en l’absence de l’option ne rien faire (donc nice=0 et ionice=B4).

Mise à jour des données

Les dernières données semblent dater d'octobre 2021 pour la plupart des codes.
Une mise à jour serait-elle possible ?
(Merci pour ce génial projet)

Calculer plusieurs exports en parallèle

L’export est l’étape qui prend le plus de temps (jusqu’à 85h pour le code du travail qui totalise 1600 versions). Dans une optique de production journalière, il pourrait être calculé plusieurs codes/textes de loi en même temps.

Cela peut se faire relativement facilement avec la bibliothèque multiprocessing et sa classe Pool ou une autre bibliothèque (je connais celle-ci mais ne suis pas particulièrement connaisseur de l’écosystème Python).

Un point à gérer est que SQLite ne semble pas spécialement apprécier les accès concurrents (j’ai essayé de lancer deux AL en ligne de commande et SQLite m’a jeté, possiblement il faut donc gérer les verrous en écriture).

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

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).

Table de matières

Ajouter une table de matières en s'appuyant sur la syntaxe kramdown. En effet, Github Pages l'utilise comme interpréteur.

On ne veut surtout pas que les articles de type ## Article L123-1 entrent dans la TdM.

Mettre les commits futurs dans une autre branche

Les dépôts Git généré font apparaitre des commits à des dates dans le futur :

2222-02-22 = code pour “date future indéterminée”
2999-01-02 = code pour null/None = pas de date de fin de vigueur [prévue]

Il serait mieux de mettre ces commits sur une branche spécifique.

Export Git de tout les textes dans un seul dépôt

Hello, c'est encore moi, en passant, une version plus pratique d'Archeo-Lex, pour ce que je fais, serait de faire un export avec un seul dépôt Git, comme ca un projet de loi devient un simple fork de ce dépôt.

Mettre les élus en commit authors

Salut,

Je ne sais pas exactement comment ça se passe et à quelles métadonnées on a accès, mais peut être qu'il serait possible de remplacer "Le législateur" comme auteur de commit par un auteur représentatif des personnes qui ont promulguées la loi ?

En particulier, mettre l'information sur les votants quelque part (si cela a un sens), ou les élus présents à la séance du vote (en croisant avec des données de regards citoyens par exemple).

Créer un cache des sections pour accélérer l’export

L’étape d’export vers Git est celle qui prend le plus de temps (jusqu’à 85h pour le code du travail qui comprend 1600 versions). Entre autres pistes qui peuvent être suivies pour améliorer cette performance, il peut être testé la chose suivante : en observant que seule une petite partie du texte est modifiée d’une version à l’autre (en général quelques articles), il pourrait être mis en cache chacune des sections du texte et réutiliser cela à la version suivante si ça n’est pas modifié.

Ce cache serait "hiérarchique" comme les sections :

• si la partie réglementaire n’est pas modifiée, la réutiliser telle quelle,
• si seul le titre I du livre I de la partie législative est modifié, réutiliser tous les autres livres ainsi que tous les autres titres du livre I.

Ce cache pourrait ou non être conservé d’une exécution à l’autre (soit reprise sur erreur, soit nouvelle livraison, soit nouveau format de sortie), aussi il faudrait que la clé du cache comprenne au moins :

• le texte LEGITEXT
• la section LEGISCTA
• le format de sortie (les différents switches "historique", "dialecte", "organisation", voire d’autres)
• possiblement la date de la base LEGI
• possiblement les articles LEGIARTI

Site web d’affichage

Désormais Archéo Lex (backend) est prêt à fournir quotitidiennement les textes de toute la base LEGI. Désormais il faut une interface web utilisable.

L’interface actuelle est basée sur GitList. Ça "fonctionne", mais l’objectif est d’avoir accès aux ~100k textes de la base LEGI, la présentation en une page ne va donc plus fonctionner. Par contre, les URLs peuvent rester ainsi (ou pas, à définir dans ce cas). Il faudra sûrement des accès via une recherche et peut-être quelques pages avec les textes par "catégories" (thèmes, nature, textes récemment modifiés, etc.) ; il n’y a pas vraiment de limites si ce n’est qu’il faut que l’ensemble reste pratique.

Noter que le paysage de la légistique numérique est en effervescence ces derniers temps avec notamment le bureau ouvert. Au-delà de vouloir faire une interface hyper-aboutie, il faut sûrement penser l’interface comme étant une proposition qui serait peut-être abandonnée et/ou forkée et/ou dont des idées seraient reprises à moyen terme dans un projet plus officiel.

fond et majo

fond comme diminutif de fondation me semble moins bien que base
majo comme diminutif de mise à jour me semble moins bien que maj

En tout état de cause, utiliser deux variables permettrait de ne pas avoir à corriger toutes les chaînes de caractères en cas de changement.

Créer un format “un répertoire par article”

Au lieu d’avoir tout un code dans un seul fichier texte, créer deux formats basés sur des répertoires :

1. des répertoires plats (flat) à raison d’un répertoire par article : /L111-1, /L111-2, /L112-1, etc.
2. des répertoires hiérarchisés par la section à laquelle ils appartiennent : /Livre Ier/Titre Ier/Chapitre Ier/L111-1, /Livre Ier/Titre Ier/Chapitre Ier/L111-2, /Livre Ier/Titre Ier/Chapitre II/L112-1, etc.

Pour le 2e format, je n’ai indiqué ici que la numérotation des sections mais il faudrait probablement y rajouter le nom de la section, sinon celui-ci n’apparaîtrait nulle part alors qu’il a son importance. Perser également à l’ordre alphabétique des répertoires utilisé par défaut par les systèmes de fichiers : par exemple un article /D111-1 se trouverait avant un article L111-1, de même des problèmes pour la numérotation romaine (c, d, i, ii, iii, iv, ix, v, vi, vii, viii, x). Réfléchir donc aux différents choix et en choisir un ou plusieurs qui seraient judicieux.

Ce type d’organisation serait beaucoup plus facile à exploiter par une machine, car plus structuré que l’actuel format d’un fichier texte qu’il faudrait parser.

On notera que lorsque la structure des sections change, et notamment le renommage, cela aurait pour effet de créer un déplacement de répertoire, ce qui n’est pas extraordinairement bien géré par Git, mais il n’y a pas le choix.

en-têtes markdown

Bonjour,

A propos des en-têtes de markdown, ne serait-li pas "mieux" de les mettre dans le "front matter", soit l'en-tête conventionnelle des fichiers markdowns au format yml ? Cela permet de séparer le contenu brut des textes des metadatas, et de pouvoir requêter sur celles-ci

merci

Hyperliens dans le corps du texte

Une autre idée en passant : Tant qu'à avoir le code numérisé, il pourrait être cool de faire des liens hypertextes entre les articles, lorsqu'ils sont référencés, pour naviguer facilement entre les articles. Et tant qu'à faire, on peut même imaginer mettre l'article référencé dans un title pour avoir tout le texte au survol de la référence :)

Stocker dans la base de données certaines métadonnées

Il y a dans la base LEGI-XML certaines métadonnées intéressantes comme les liens, mais peut-être également d’autres. Ces métadonnées ne serviraient probablement pas dans une version “texte brut” mais seraient intéressantes à exploiter dans des versions “texte enrichi” ou “machine-readable”.

Les premières étapes seraient :

• étudier les métadonnées intéressantes à stocker dans la base de données (travail sans qu’il y ait besoin de compétence en programmation, mais surtout de la curiosité pour parcourir quelques textes et juger de l’intérêt des différentes métadonnées + lecture de doc)
• définir un schéma de base de données pour cette fonctionnalité : quelles sont les champs à stocker ?
• stocker dans la base de données les métadonnées à ajouter

Dans un second temp, on pourra envisager de réutiliser ces métadonnées pour améliorer #2 et #18.

Dans un troisième temps, dans le cadre d’Archéo Lex ou pas (plutôt “pas” en fait), on pourrait comparer les résultats obtenus selon les deux méthodes (source officielle et reconstruction heuristique), et en fonction des cas améliorer les heuristiques ou rapporter l’erreur de liens à la DILA – selon que c’est un faux positif ou un faux négatif en fait – et dans ce cadre ça rentrerait dans le cadre de legi.py (@Changaco).

Je mentionne cette feature ici parce qu’il faut bien le mettre quelque part et que c’est d’intérêt pour Archéo Lex, mais ça rentrerait dans un projet plus global à Légilibre d’avoir une structure de base de données commune entre les différents projets.

Multiple VCS backends

Git is not the only one VCS. Mercurial and Bazaar are great too. It could be good to have a multi-backends architecture + Git support, so anyone could add other VCS (mercurial and bazaar are Python libs, so this could be done quite easily).

Ajouter les en-têtes et pieds-de-page

Il manque actuellement les en-têtes (visas, attendus, etc.) et pieds-de-page (signataires, nota, etc.), il faudrait les ajouter.

Selon le type d’organisation prévu, cela peut être fait de façon différente :

• dans la version "fichier-unique", les en-têtes irait naturellement après les métadonnées (cf #50), et après la fin du texte pour les pieds-de-page ; à voir s’il faut faire une section markdown par type d’en-tête (genre " # Visas ") ou si c’est mis en plein texte directement (a priori je pencherais pour des sections)
• dans les versions "par article", je dirais qu’il faut ajouter un fichier par type d’en-tête et pied-de-page ? genre /visas, /signataires

Une question commune est : faut-il créer des sections ou fichiers vides lorsque l’en-tête/pied-de-page est vide ? Par exemple s’il n’y a pas de visas, faut-il créer une section markdown "# Visas" vide ou un fichier /visas vide ?

Utiliser legi.py comme base de données

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.

Du nouveau ?

Hello,

J'essaie tant bien que mal de faire fonctionner le script, dont le résultat correspond parfaitement à mes besoins (.md de codes entiers versionnés) mais je suis malheureusement novice en Python.. Et le debug est loin d'être simple, j'ai l'impression que le repo n'est pas à jour et ne peut pas fonctionner "en l'état", les tables "livraisons" ne sont pas créées.

Le projet est-il abandonné ? Possible d'avoir une petite update ou coup de pouce pour pouvoir juste mouliner mes md versionnés ?
Les nombreux projets sur ce sujet sont tous tombés en désuétude.. (Steeve) dommage !

Actuellement, j'en suis là (J'ai ajouté manuellement les tables de livraisons à la base Sqlite) :

Modéliser les alinéas

Pour ce faire, il faut surtout des compétences en légistique, il s’agirait de pouvoir segmenter automatiquement les alinéas, c’est-à-dire décrire les règles qui font qu’on change d’alinéas.

Pour commencer simple, un alinéa est bien un paragraphe ?

Peut-on avoir un retour à la ligne ou une ligne vide à l’intérieur d’un alinéa ?

Ensuite, que se passe-t-il si on a une liste ? Les éléments de la liste appartiennent-ils tous au même alinéa ?

Et si on a un tableau ? Comment est-ce compté ?

Il s’agirait d’écrire une petite doc. Pour cette doc, il ne devra pas être utilisé l’expression « ça dépend », car ensuite le programme qui en sera fait n’a pas la capacité de raisonnement et d’analyse d’un humain habitué à lire de la légistique. Ensuite, de cette doc, il pourra être écrit un algorithme.

Licence Archéo Lex (problème avec la GPL)

La licence d'Archéo Lex est censée être la WTFPL.

L'utilisation de html2text imposerait une mise en conformité par un passage à la licence GPL, ou a minima l'arrêt immédiat de l'usage de cette bibliothèque.

Cependant, un passge à la GPL pourrait être la meilleure option vu les dépendances souhaitables d'Archéo Lex :

• Git est sous GPL
• Pygit2 est sous GPL
• Mercurial est sous GPL
• Bazaar est sous GPL

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

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é.

UNIQUE constraint failed

Lancé sur un scaleway tout neuf les commandes indiquées dans le README:

python -m legi.download ./tarballs
python -m legi.tar2sqlite legi.sqlite ./tarballs

Et ça plante (au bout d'une petite heure à la louche) pendant le tar2sqlite:

deleted 381 rows based on liste_suppression_legi.dat: {"articles": 85, "liens": 137, "sections": 7, "sommaires": 128, "textes_structs": 12, "textes_versions": 12}
last_update is now set to 20170629-205629
> Processing legi_20170630-204118.tar.gz...
duplicate_files
    (u'other_cid', u'JORFTEXT000033578386')
    (u'sous_dossier', u'texte/struct')
    (u'other_dossier', u'TNC_non_vigueur')
    (u'other_mtime', 1498848089)
    (u'cid', u'JORFTEXT000033578386')
    (u'dossier', u'TNC_en_vigueur')
    (u'mtime', 1498762615)
    (u'id', u'LEGITEXT000033583880')
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/root/venv/lib/python2.7/site-packages/legi/tar2sqlite.py", line 429, in <module>
    main()
  File "/root/venv/lib/python2.7/site-packages/legi/tar2sqlite.py", line 405, in main
    process_archive(db, args.directory + '/' + archive_name)
  File "/root/venv/lib/python2.7/site-packages/legi/tar2sqlite.py", line 206, in process_archive
    'other_mtime': mtime,
  File "/root/venv/local/lib/python2.7/site-packages/legi/utils.py", line 107, in insert
    """.format(or_clause, table, keys, placeholders), values)
sqlite3.IntegrityError: UNIQUE constraint failed: duplicate_files.id, duplicate_files.sous_dossier, duplicate_files.cid, duplicate_files.dossier

Une idée ou je creuse? :)

Connecter Archéo Lex avec the-law-factory-parser

Faire en sorte que Archéo Lex soit compatible avec https://github.com/promethe42/the-law-factory-parser/tree/feature/parse_texte_ast, c’est-à-dire utiliser AL comme source de données de la loi et the-law-factory-parser comme compréhension informatique des amendements ; les deux connectés permettraient de calculer l’application des amendements sur la loi actuelle.

Certificat HTTPS expiré

Pour info, le certificat HTTPS de archeo-lex.fr, a expiré le 15 avril 2018:

Mettre en place une infrastructure de tests

Attendu que l’objectif d’Archéo Lex est de créer des dépôts Git et que tout changement même infime dans les données écrites (textes, organisation des fichiers, textes des commits, métadonnées des commits) entraîne la création d’un historique Git entièrement différent,

Déclare qu’il serait très souhaitable de mettre en place des tests unitaires et tests d’intégration pour être averti des modifications dans les dépôts Git issus d’Archéo Lex, pour décider en connaissance de cause si on doit casser la compatibilité ascendante.

Formatage Markdown des tableaux

Actuellement les tableaux sont en HTML, et certains diffs montrent des retours à la ligne alors que ceux-ci ne sont que liés à la représentation HTML sans influence sur le contenu. Il faudrait nettoyer cette soupe de balises HTML et avoir une jolie représentation textuelle des tableaux.

La version GitHub du Markdown possède cette syntaxe, je trouve ça pas mal, elle a l’avantage d’être lisible. Vérifier s’il est possible de fusionner verticalement ou horizontalement des cellules ou, à défaut, si c’est bloquant en recherchant dans des textes de loi.

Voir aussi cette discussion sur Meta Stackoverflow.

[nuitducodecitoyen2018] Plantage si données maquantes

L'application semble planter lorsque les fichiers de données manquent.

! python2.7 archeo-lex 
Création de l’historique (legi.py)
> Texte LEGITEXT000006069414
Traceback (most recent call last):
  File "archeo-lex", line 169, in <module>
    principal(docopt(aide, help=False))
  File "archeo-lex", line 162, in principal
    textes = creer_historique_legi(data['textes'], data['format'], data['dossier'], data['cache'], data['bddlegi'])
  File "/work/nuitducode/Archeo-Lex/marcheolex/exporterlegi.py", line 90, in creer_historique_legi
    texte_traite = creer_historique_texte(texte, format, dossier, cache, bdd)
  File "/work/nuitducode/Archeo-Lex/marcheolex/exporterlegi.py", line 119, in creer_historique_texte
    last_update_jour = datetime.date(*(time.strptime(last_update, '%Y%m%d-%H%M%S')[0:3]))
  File "/usr/lib/python2.7/_strptime.py", line 478, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.7/_strptime.py", line 329, in _strptime
    found = format_regex.match(data_string)
TypeError: expected string or buffer

Exporter directement au format Git-pack

Sur le conseil d’Emmanuel Raviart, il serait intéressant d’enregistrer directement au format Git-pack sans passer par le binaire Git. Cf la librairie Dulwich qui document le format Git-pack.

Affichage des dates inférieure à 1970 erroné

Par exemple, sur cette page: https://archeo-lex.fr/codes/code-de-l%E2%80%99artisanat

Les commits eux aussi ont la mauvaise date:

commit 9d4ab729ba0f9346fb8f75155985f9530d568a2b
Author: Législateur <>
Date:   Tue Feb 6 00:00:00 2018 +0100

    Version consolidée au 18 juin 1954
    
    Versions :
    - base LEGI : 18 juillet 2014 11:30:10
    - programme Archéo Lex : 0.2.0-alpha

commit 605f346a69a5b2ee9f32979841a6964ceb9d2369
Author: Législateur <>
Date:   Fri Feb 7 00:00:00 2020 +0100

    Version consolidée au 20 juillet 1952
    
    Versions :
    - base LEGI : 18 juillet 2014 11:30:10
    - programme Archéo Lex : 0.2.0-alpha

La solution à l'air d'être d'utiliser un autre format que le timestamp pour spécifier la date: https://stackoverflow.com/questions/19742345/what-is-the-format-for-date-parameter-of-git-commit

Du coup, a cette ligne, en théorie il faudrait faire:

    ...ateur <>"', '--date=short:"' + debut..strftime("%Y-%m-%d") + '"', '-m', 'Version consolidée au...

Par contre, pas moyen de faire fonctionner cette solution. Du coup soit changer l'affichage des dates, soit regler les dates dans git.

Refondre Archéo Lex et le format sous-jacent

Depuis quelque temps j’ai dans la tête de refondre Archéo Lex en prenant avantage de l’expérience accumulée jusque là, et cela passerait entre autres sur une formaliation de la spec du format utilisé et, dans mon idée, une réécriture de Archéo Lex en JavaScript.

La formalisation de la spec du format a déjà vu une tentative dans le fichier doc/format.md qui est plus ou moins une photographie du format actuel d’Archéo Lex, mais j’aurais bien d’autres éléments à ajouter pour prendre en compte :

• affirmer le rôle pragmatique d’une telle spec : son but premier ne serait pas d’être une base de données exhaustive du corpus législatif (cela est plutôt dévolu aux bases sources de la DILA et à leurs versions SQL (via legi.py par exemple)) mais plutôt un format pratique pour permettre d’autres traitements : diffusion plus pratique, interopérabilité, intégration avec de nombreux outils et écosystèmes, exploitation dans d’autres traitements (metslesliens, DuraLex, comptage facilité des alinéas, autres traitements NLP, création d’outils de visualisation facilitée, etc.), caractère immutable des objets Git.
• créer un format polymorphe : les débats passés et le but pragmatique montrent qu’il est compliqué de définir un format qui réponde à l’ensemble des contraintes et des objectifs : en conséquence je trouve qu’il serait plus sage de définir une famille cohérente de formats adaptée aux différentes situations.
  Par exemple d’un côté un repo Git avec l’ensemble des lois dans le dossier principal (ou dans des sous-dossiers par nature), et d’un autre côté un repo Git avec seulement un code par branche. Par exemple le premier pourrait servir à de la recherche plein texte dans tout ou partie des versions actuelles des textes (quoique pas forcément très efficace) ou à de la veille législative, et le deuxième à la création d’analyses statistiques sur la fréquence de modification de chaque code. Chacun de ces découpages "par texte puis temporel" versus "temporel puis par texte" aurait un intérêt, selon les objectifs, pour prioriser des traitements lourds selon si l’on s’intéresse à toute l’histoire de certains textes ou surtout à l’histoire récente.
  Selon les usages, on peut vouloir tout ou partie du corpus législatif et réglementaire (voir par exemple #64 en opposition avec le format actuel d’un texte par repo Git).
  Je ne discute pas ici plus avant des différentes options sur les formes, mais cela a à voir avec les objectifs poursuivis et les ressources et la technicité qu’on est prêt à y engager.
• créer un format extensible : je n’ai pas d’idées arrêtées, mais je me dis qu’on peut imaginer utiliser par exemple git-notes pour enrichir les données. Par exemple, on pourrait vouloir attacher à chaque commit un CSV avec les liens vers d’autres textes (localisation du lien dans le texte + destination).
• faciliter la définition des références légistiques : les textes sont très fortement liés au sens juridique avec d’une part les liens entre textes et d’autres part les actions modificatrices des textes récents sur les textes plus anciens : il serait souhaitable que le format facilite autant que faire se peut la création de références afin de naviguer facilement dans le corpus des textes.
  Même si in fine il faut s’appuyer sur des algorithmes pour localiser tel mot de tel alinéa dans tel article de tel code, le format global devrait être conçu de façon à faciliter le plus possible ces algorithmes, notamment avec des conventions de nommage claires : comment gère-t-on les titres, comment gère-t-on les annexes (par ex. État A/B/C/… des lois de finances, tableaux, code annexé à une ordonnance de codification, etc), comment gère-t-on les articles non-nommés ou lorsque deux articles ont le même nom [sic], conventions de nommage sur les textes non-numérotés (arrêtés, circulaires, textes anciens, etc.), etc.
  Les URIs ELI peuvent avoir leur utilité pour une grande partie des textes récents, mais il y a d’autres cas plus particuliers ou plus anciens. Cette problématique se pose également s’il s’agissait de gérer des textes en projet (projets/propositions de loi, projets de décrets, etc.), des textes réglementaires spéciaux (par ex. des décisions d’AAIs (CNIL, AMF, CADA, ASN, etc.) ou « extra-réglementaires » (cahiers des charges des AOCs par ex.).
• gérer le caractère évolutif de la spec : cela est assez standard que les specs évoluent, mais celle-ci pourrait évoluer relativement souvent pour prendre en compte de nouveaux cas particuliers pour les références, l’ajout de nouveaux domaines juridiques (une nouvelle AAI, l’ajout de la législation européenne, italienne, marocaine, etc.)

À noter que le format Git permet de pouvoir stocker dans un même repo, à bas coût, plusieurs formes similaires des textes et de distribuer ensemble ou indépendemment ces formes, ceci de part ses caractéristiques internes (stockage d’objets, compressés et avec compression delta dans les packfiles) et externes (distribution de branches). Lors de la génération du/des repos Git, il serait de bonne programmation que d’écrire les différentes formes demandées en même temps, par exemple écrire la branche "tous textes" et les branches de chaque texte indépendant en même temps vu qu’on introduit des commits ayant les mêmes objets Git (les textes).

En lien avec cette formalisation, j’ai dans l’idée de réécrire Archéo Lex en JavaScript afin d’avoir le même langage que metslesliens et DuraLex-JS afin que Archéo Lex ait un rôle de coordinateur dans la production des dépôts Git et de versions alternatives enrichies de ces deux librairies (je précise toutefois pour ces deux librairies que je souhaite qu’elles conservent une version secondaire en Python via un portage partiel des grammaires PEG.js vers les grammaires Parsimonious/Python étant donné la similarité des dialectes). Mais c’est aussi que j’ai personnellement tendance à préférer désormais le JavaScript au Python, même si cela est subjectif.

Dans cette nouvelle version d’Archéo Lex, j’aurais comme objectifs sur son architecture :

• la performance : en gérant au mieux la mémoire, le CPU et le disque, afin d’être le plus rapide possible pour la mise à jour quotidienne d’un grand nombre de textes
• la modularité : en essayant de ne pas faire trop obstacle à la performance, pour pouvoir utiliser des parties de l’ensemble sans trop d’inter-dépendances internes et pouvoir ainsi ajouter de nouvelles extensions (métadonnées sur les liens, etc.) ou domaines juridiques (législation européenne, etc.)

Pas de texte avec cet ID ou CID

Bonjour,

petit souci ce matin :)

Dernière mise à jour de la base LEGI : 2018-02-01T19:55:53+01:00
Traceback (most recent call last):
  File "./archeo-lex", line 148, in <module>
    principal(docopt(aide, help=False))
  File "./archeo-lex", line 145, in principal
    creer_historique_legi(data['textes'], data['format'], data['dossier'], data['cache'], data['bddlegi'])
  File "/code/marcheolex/exporterlegi.py", line 89, in creer_historique_legi
    creer_historique_texte(texte, format, dossier, cache, bdd)
  File "/code/marcheolex/exporterlegi.py", line 135, in creer_historique_texte
    raise Exception('Pas de texte avec cet ID ou CID')
Exception: Pas de texte avec cet ID ou CID

Limiter les noms de fichiers à 255 caractères

@revolunet a proposé un fix dans #59 (qui est mergé) afin de se prémunir d’une erreur d’écriture lorsqu’un fichier a plus de 255 caractères (problème sous Mac pour @revolunet). Ceci concerne surtout le système d’organisation "sections" où les dossiers correspondent aux titres (parfois longs) et les articles sont dans les dossiers.

En étudiant de mon côté sous Linux (ext4), je constate que c’est chaque fichier qui doit faire moins de 255 caractères, ça serait donc plus souple que ce qui est actuellement dans Archéo Lex (où le chemin total doit faire moins de 255 caractères). @revolunet: est-ce bien cela également sur Mac ?

D’autre part, cette nouvelle version me fait des bugs car ce sont les derniers caractères qui sont conservés donc ça peut sortir du dossier conteneur ("textes" par défaut) puisque l’opération est effectuée après (ceci sera/serait résolu en limitant uniquement chaque niveau à 255 caractères).

Un point de discussion est de prendre le début ou la fin du nom de fichier lorsqu’on tronque. C’est la fin qui est actuellement prise, mais je trouverais plus logique de prendre le début, notamment pour avoir le titre ("Chapitre III", "Paragraphe 2", etc.), mais bien sûr en conservant l’extension (et le début de titre "Article_" le cas échéant).

Aussi, plus précisément, il semble que certains systèmes de fichiers aient un maximum de 255 octets comme ext4 et btrfs, quoique certains semblent avoir 255 caractères (d’après Wikipédia en français). En testant sur Linux avec ext4, ce sont bien des octets (un "é" prend la place de 2 "a").

Enfin, peut-être le plus important : dans une optique de portabilité et de reproductibilité – pour avoir numéros de versions Git reproductibles – il serait souhaitable de définir une limite absolue et non dépendante de la plate-forme, ou en tous cas avoir une option de configuration (comme l’actuelle --dates-git qui permet de gérer les dates avant 1970 mais en rendant les dépôts non-compatibles avec GitHub) qui permette de générer :

• soit avec cette limite absolue (probablement 255 qui semble assez standard, au moins Mac et Linux)
• soit le maximum possible sur la plate-forme (l’implémentation actuelle)
• soit pas de limite (en lien avec #51, je vais bientôt exporter directement en écrivant les objets Git, donc je pourrai probablement m’affranchir de cette limite, même si je n’ai aucune idée s’il serait alors possible d’ouvrir les dépôts Git créés, donc ce n’est pas non plus forcément souhaitable).

PS : d’après une recherche rapide, sur les versions actuelles des codes, je ne trouve que le "titre XXI bis" du code de procédure pénal qui a un titre (donc un seul niveau) qui fait plus de 255 caractères (271 exactement), mais cela n’empêche qu’il faut traiter le cas.

Traiter différemment les codes abrogés

Actuellement, lorsqu’un code est abrogé (par exemple la plupart des codes de déontologie comme le code de déontologie des sages-femmes), la dernière version générée par Archéo Lex est la dernière version en vigueur.

Je pense que ce comportement n’est pas optimal, car cela ne crée pas de distinction entre les codes abrogés et ceux en vigueur. Par exemple, si on met tous les codes dans un dossier et qu’on y fait des recherches, on a à la fois des codes en vigueur et des codes abrogés.

> La principale idée que j’ai pour traiter cette différence est de supprimer le fichier texte à la date d’abrogation et d’enregistrer dans Git cette version vide.

Une autre idée à affiner serait de renommer la branche "texte" (ou "sections" ou "articles" selon l’organisation des fichiers) en une branche "texte-abrogé" (resp). Ainsi, lorsqu’on prendrait tous les codes dans leurs branches "texte", on n’aurait pas les textes abrogés. Ce comportement serait similaire à ce qui est fait actuellement pour les textes en vigueur future qui ont seulement une branche "texte-futur" (ces codes n’ont pas de vigueur actuelle, par exemple le futur code de la commande publique qui entrera en vigueur le 1er avril 2019, sauf blague).

Il est aussi possible de combiner les deux idées ci-dessus en renommant la branche "texte" en "texte-abrogé" et en y enregistrant une version vide à la date d’abrogation.

Des idées ou remarques ?

Articles sans date de début

Certains articles ont des plages de vigueur 2999-01-01 – 2999-01-01, autrement dit ils sont présents depuis la nuit des temps (passée) pour l’éternité (future), sauf décision contraire à venir :-) c’est le cas par exemple des trois premiers articles de la loi n° 2017-242 (les 2 derniers ne sont en vigueur que depuis le 1er mars 2017 et pour l’éternité).

Cela fait que les 3 premiers articles de cette loi n’apparaissent pas lorsque la loi est générée par Archéo Lex.

En explorant la base LEGI, il existe des articles ayant une date de début à 2999-01-01 et une date de fin réelle (=pas 2999-01-01) ; ce sont par exemple les articles 24, 29 et 35 de la loi n° 2014-1653. Je pense qu’il faut donc avoir la stricte équivalence « articles.date_debut = '2999-01-01' <=> articles.date_debut = textes_versions.date_debut » (avec les noms de champs de legi.py).

Code rural

Plusieurs codes ont plusieurs versions successives rangées dans des identifiants entièrement différents, et souvent notés avec "(nouveau)" ou "(ancien)" dans le titre, c’est le cas pour "code de commerce", "code de justice militaire", "code de la route", "code forestier", "code minier", "code pénal", "code des marchés publics", "code rural".

Pour le code rural et le code des pensions militaires d'invalidité et des victimes de la guerre, voici les enregistrements legi.py :

• id | cid | début | fin | état | titre | titrefull
• LEGITEXT000006071366|LEGITEXT000006071366|1955-04-19|2999-01-01|VIGUEUR|Code rural (ancien)|Code rural (ancien)
• LEGITEXT000006071367|LEGITEXT000006071367|1979-12-01|2010-05-08|MODIFIE|Code rural|Code rural (nouveau)
• LEGITEXT000022197698|LEGITEXT000006071367|2010-05-08|2999-01-01|VIGUEUR|Code rural et de la pêche maritime|Code rural et de la pêche maritime
• LEGITEXT000006074068|LEGITEXT000006074068|1951-04-26|2017-01-01|MODIFIE|Code des pensions militaires d'invalidité et des victimes de la guerre|Code des pensions militaires d'invalidité et des victimes de la guerre
• LEGITEXT000031712069|LEGITEXT000006074068|2017-01-01|2999-01-01|VIGUEUR|Code des pensions militaires d'invalidité et des victimes de guerre|Code des pensions militaires d'invalidité et des victimes de guerre

On remarque que ce sont les 2 seuls codes à avoir une version avec un état 'modifié' et à partager leurs numéros de cid.

Cela n’est pas bien géré actuellement par Archéo Lex car le cid donne 2 noms de répertoires différents, mais il faut comprendre ce qui se passe pour gérer correctement.

Langue à utiliser en priorité / language to be used in priority

[English below]

Le code et l’interface en ligne de commande d’Archéo Lex sont pour l’instant quasi-entièrement en français, ce qui est assez inhabituel dans le monde du logiciel où l’anglais est la lingua franca. J’avais fait ce choix lors du développement initial d’une part pour être original, d’autre part parce que ce logiciel est destiné principalement à la France, et en partie par militantisme pour le multilinguisme.

Ce point de discussion (issue) met au débat, voire au vote, cette question : « faut-il utiliser l’anglais ou co-l’utiliser avec le français pour tout ou partie du code et/ou de l’interface en ligne de commande et/ou de la documentation et/ou des discussions comme par exemple les problématiques (issues) ? ».

Bien sûr, il est question de façon sous-jacente de la conception qu’on a chacun de la place des langues et pour partie de la possible réutilisation d’Archéo Lex dans d’autres espaces linguistiques. Bien sûr, cette question est un peu du bikeshedding (la nécessairement importante discussion sur la couleur de l’abri à vélo), mais c’est parfois nécessaire de discuter des goûts et des couleurs.

---

[français ci-dessus]

The code and the command line interface of Archeo Lex are for now almost entirely in French, which is quite unusual in the software world where English is the lingua franca. I did once this choice during the initial development parly for originality, partly because this software is mainly intended for France, and partly to promote multilinguism.

This discussion topic (issue) opens for debate, if not for voting, this question: “should we use English or co-use with French, partly or for the whole of code and/or command line interface and/or documentation and/or discussions like issues?”.

Accordingly the underlying matters are related to our own conceptions of the languages, and partly the possible reuse of Archeo Lex in other linguistic areas. Accordingly this question is a bit of bikeshedding (the necessarily important discussion of the bikeshed colour), but sometimes it is necessary to discuss tastes and colors.

Fichier manquant dans le code de l’urbanisme

Dans le code de l’urbanisme (LEGITEXT000006074075), AL fait correctement la mise en base de données (option CLI --ranger), mais l’export Git plante à la première version avec le message

IOError: [Errno 2] No such file or directory: u'cache/bases-xml/legi/global/code_et_TNC_en_vigueur/code_en_vigueur/LEGI/TEXT/00/00/06/07/40/LEGITEXT000006074075/article/LEGI/ARTI/00/00/31/39/86/LEGIARTI000031398648.xml'

Cet article est référencé dans LEGISCTA000006175987, mais il n’y a effectivement pas d’article LEGIARTI000031398648 ni de lien vers cet article depuis d’autre articles (pas obligatoire mais ça aurait été possible). Dans la section, cet article est décrit comme

<LIEN_ART debut="2015-10-31" etat="VIGUEUR" fin="2999-01-01" id="LEGIARTI000031398648" num="R425-29-1" origine="LEGI"/>

La version de la base LEGI utilisée est 20170217-212119.

---

Même problème avec le Code de l’action sociale et des familles (LEGITEXT000006074069) sur l’article LEGIARTI000033706110 décrit dans la section LEGISCTA000018780362 comme :

<LIEN_ART debut="2016-12-29" etat="VIGUEUR" fin="2999-01-01" id="LEGIARTI000033706110" num="Annexe 1-2" origine="LEGI"/>

À la différence de l’exemple précédent, cet article est référencé depuis d’autres articles, par exemple LEGIARTI000021940980.

Ajouter les lois et ordonnances

Hello, j'utilise les exports bruts des codes pour appliquer le texte un projet de loi (= SedLex à la main). Par contre, il n'y pas encore les lois et les ordonnances, par exemple l'ordonnance n° 58-1100 du 17 novembre 1958 ou encore la loi du 12 juillet 1937 instituant une caisse de retraite et d’assistance des clercs de notaires. Un petit ticket juste pour dire que ça me serais utile.

dépôt git avec la constitution

Bonjour,

dans le cadre du projet Amenda (une sorte de gitlab pour les projets de loi), nous avons besoin de la constitution (avec son historique) dans un dépôt git.

Possible ?
Comment ?

Manquement de paragraphes dû aux versionnage de sections

Parfois le fichier obtenu manque quelques paragraphes dans certaines sections : cela vient du fait que les modifications chronologiques des sections deviennent trop complexes...

LEGISCT1 -> Chapitre I ancien
LEGISCT2 -> Chapitre I nouveau
LEGISCT3 -> Section 1, dont le id_parent est LEGISCT1, mais en vigueur dans la nouvelle version

Dans cette configuration, Section 1 disparaît dans la nouvelle version.

Je n'ai pas encore tout à fait compris votre base de données, mais le workaround que j'ai trouvé, au lieu de faire

articles_section = articles.select().where(Article.version_section == version_section_parente)

est de prendre maintenant toutes les possibilités

articles_section = articles.select().where( (Article.version_section == version_section_parente.cid.cid) | (Article.version_section == version_section_parente))

Idem pour les sections, dans le fichier exporter.py.

Problème dans l'interface CLI

La CLI ne comporte que des options, dont certaines devraient être des commandes ou des arguments.