Je travaille depuis quelque temps sur Elpe, un projet qui vise à obtenir les bonnes propriétés de Nix/NixOS (les mises à jour atomiques, la reproductibilité), mais avec des paquets Ubuntu.

Le code : https://nest.pijul.com/pmeunier/elpe

L'idée est de définir des recettes de compilation en OCaml et de les envoyer à un backend Rust, qui se charge de les exécuter dans un conteneur sans réseau, en exposant uniquement le contexte nécessaire à la bonne exécution de la compilation. Les produits du build sont indexés par le contenu de la recette du build, et indexés une deuxième fois par le résultat : c'est ce deuxième hash qui est utilisé dans les dépendants du paquet, ce qui permet de construire un arbre de Merkle du système complet (et non seulement de ses sources), qui rend toute modification ultérieure facilement détectable.

De plus, le système de base provient des dépôts de paquet Debian ou Ubuntu. Cependant, tous les chemins sont hard-codés (comme dans Nix), ce qui permet de garantir la reproductibilité, au détriment toutefois du coût de mise à jour en termes d'espace et opérations disque.

Si le choix de Rust devient relativement consensuel par les temps qui courent, OCaml est plus surprenant. Après divers essais avec plusieurs langages, je l'ai choisi parce que c'est le seul langage avec à la fois :

• Une bonne approximation du système de types dont j'avais besoin: typage nominal et aussi structurel, entre autres.
• Un système de types relativement simple (pas de typeclasses ni de monades comme en Haskell, de borrow checkers comme en Rust ni de types dépendants comme en TypeScript).
• Du late binding, nécessaire pour exprimer des "overrides" et des "hooks", courants quand on veut compiler des choses (autoconf et make ont plein d'options de ce type, par exemple).
• Un compilateur ultra-rapide.
• Un bytecode, pour (dans le futur) contrôler aussi l'isolation du code de build de façon très légère.

La simplicité et l'expressivité d'OCaml sont bien adaptés à ce projet: les fonctions simples à concevoir y sont relativement claires à énoncer.

Pourquoi pas NixOS, me direz-vous ? En tant qu'utilisateur et contributeur depuis environ 10 ans, un certain nombre de problèmes plus ou moins récents m'ont motivé à explorer une alternative:

• En termes de gouvernance, la communauté a traversé dans la dernière année plusieurs crises de différentes tailles (Anduril, Devenv…). On pourrait y voir un signe de maturation ou au moins de croissance du projet, mais plusieurs éléments me permettent d'en douter, dont les réactions répétées de la fondation Nix, qui semble avoir beaucoup de mal à comprendre les messages pourtant clairs des contributeurs.

• Je vois aussi les choix de design imposés par les fondateurs du projet depuis quelques années comme un bien mauvais signe: les flakes (en 2020) étaient une première incarnation de cette tendance, et plus récemment la "distribution propriétaire" de Nix est clairement une mauvaise idée, alors que la qualité de code de Nix n'est pas au niveau où on l'attendrait et que le gros du projet repose depuis plusieurs années sur le travail pharaonique des contributeurs de Nixpkgs.

• On pourrait parler longtemps de la sécurité de Nix, qui me fait de plus en plus peur y compris pour mon usage personnel. Les process de gestion des rapports ne me conviennent pas, de même que l'opacité de certains choix techniques (les flags de compilation désactivés sur certaines plateformes, entre autres), souvent bien cachés dans les entrailles de Nixpkgs.

• Enfin, le langage trop complexe à utiliser (principalement par manque de typage statique et de messages d'erreurs pertinents) rend Nix difficile à utiliser au sein d'une organisation d'une taille importante, et encourage les comportements peu inclusifs (éviter d'écrire de la doc, inventer des casse-têtes pour faire des choses simples…). Je suis bien sûr conscient que des entreprises (comme Anduril) et des ONGs (comme Médecins Sans Frontières) l'utilisent, mais je ne pense pas que ce soit généralisable aux situations où j'aimerais voir ce genre de projet utilisé.

Pour les lecteurs pressés retenez que LA grande nouveauté de la V2 est la gestion des calc (xlsx, ods,…)

Pour rappel : LOTemplate est un générateur de documents sous licence AGPL v3 qui permet de créer des documents (ODT, DOCX, ODS, XLSX, PDF, …) à partir d'un document modèle office et d'un fichier json pour les données. Cela devrait intéresser toute personnes qui a déjà essayé de générer du doc/odt ou excel/calc à partir de son code.

LOTemplate offre des caractéristiques permettant une intégration simple dans tout projet et permettre la gestion de modèle de document a partir de modèle office :

• Les modèles sont au format bureautique (ods,odt, docx, xlsx, … )
• Les modèle peuvent avoir des structures complexes (variables, boucle, conditions, compteurs, html,…)
• L'outil peut scanner le modèle pour extraire la feuille de variables
• L'outil peut être appelé par une API, une CLI ou un module Python.
• L'outil utilise un LibreOffice headless pour remplir les modèles donc 100% compatible avec Libreoffice.
• Les formats de sortie sont tous les formats pris en charge par LibreOffice (docx, xlsx, pdf, odt, ods, texte, rtf, html, etc.).

Intégrer LOTemplate c'est permettre à un utilisateur lambda de partir de ses documents office pour intégrer ses modèles dans l’application sans avoir à maîtriser des technologies spécifiques et complexes.

Pour aller plus loin vous trouverez dans la documentation :

• deux schémas qui expliquent le fonctionnement de Lotemplate (schema)
• un exemple d’utilisation très parlant dans la doc ;
• des exemples dans les tests unitaires.

Et surtout n’hésitez pas à l’utiliser, faire vos retours et bien sûr contribuer.