OxyMake: A Formally-Specified, Content-Addressable Workflow Engine

OxyMake est un moteur de workflow en Rust, spécifié formellement et contenu dans un binaire unique, qui remplace les horodatages de modification de fichiers peu fiables par le hachage BLAKE3 adressé par le contenu afin d'assurer une mise en cache robuste et multi-machines et d'éliminer les réexécutions intempestives tout en maintenant la compatibilité avec les pipelines de type Make existants.

L'essentiel

Imaginez que vous dirigiez une compétition de cuisine massive s'étendant sur plusieurs jours. Vous avez un livre de recettes (le flux de travail ou workflow) qui vous explique comment transformer des ingrédients bruts en un festin final.

Autrefois, le chef de cuisine (les moteurs de workflow comme GNU Make ou les premières versions de Snakemake) décidait de recuire un plat en se basant sur une règle très simple : « Est-ce que l'horloge sur le bocal d'ingrédients a changé ? »

Cela revient à vérifier l'horodatage « Dernière modification » d'un fichier. Mais cette règle est défectueuse.

• La fausse alerte : Si vous déplacez vos ingrédients dans une nouvelle cuisine, ou si vous les restaurez à partir d'une sauvegarde, les bocaux reçoivent de nouveaux horodatages même si la nourriture à l'intérieur est identique. Le vieux chef voit le nouveau temps, panique et recuit tout le repas à partir de zéro, gaspillant des heures de temps et d'énergie.
• L'échec silencieux : À l'inverse, si vous remplacez la nourriture à l'intérieur d'un bocal sans changer l'étiquette du bocal (l'horodatage), le chef voit l'ancien temps, suppose que tout va bien et vous sert une nourriture rance ou avariée sans s'en rendre compte.

OxyMake est un nouveau moteur de cuisine super intelligent conçu pour corriger cela. Au lieu de regarder l'horloge sur le bocal, il goûte la nourriture (vérifie le contenu réel).

Voici comment fonctionne OxyMake, décomposé en concepts simples :

1. Le « Test de Goût » (Mise en cache par adresse de contenu)

Au lieu de demander « Quand cela a-t-il été touché pour la dernière fois ? », OxyMake demande : « De quoi cela est-il fait ? »
Il crée une « empreinte digitale » unique (un hachage cryptographique) pour chaque ingrédient, chaque étape de la recette et chaque outil utilisé.

• Si vous copiez vos ingrédients dans une nouvelle cuisine, les empreintes restent les mêmes. OxyMake voit qu'elles n'ont pas changé et dit : « Pas besoin de cuisiner ; nous avons déjà le plat parfait. »
• Si vous remplacez une tomate par une pomme de terre, l'empreinte change instantanément. OxyMake sait immédiatement que le plat est différent et ne cuit que la partie spécifique qui doit être modifiée.

Cela élimine les « réexécutions fantômes » (perdre du temps à cuisiner ce que vous avez déjà) et les « sorties périmées silencieuses » (servir une mauvaise nourriture parce que l'étiquette semblait correcte).

2. Le « Plan vs La Construction » (Architecture à trois graphes)

OxyMake réfléchit en trois couches, comme un architecte, un bâtisseur et un contremaître :

• Le Plan (RuleGraph) : C'est votre livre de recettes. Il est abstrait. Il dit : « Préparez une soupe pour chaque légume. » Il ne sait pas encore de quels légumes il s'agit.
• Le Plan de Construction (JobGraph) : OxyMake prend le plan et l'étend. « D'accord, nous avons des carottes, des pommes de terre et des oignons. Cela signifie que nous devons préparer trois soupes spécifiques. » Il détermine exactement ce qui doit être fait avant de commencer à cuisiner.
• Le Chantier (ExecGraph) : C'est la cuisine réelle en cours. Il suit quelle marmite bout, laquelle est terminée et laquelle a brûlé.

Parce qu'OxyMake planifie tout à l'avance (en une fraction de seconde), il peut gérer d'énormes recettes comprenant des milliers d'étapes bien plus rapidement que les autres moteurs qui essaient de comprendre ce qu'ils font au fur et à mesure.

3. La Cuisine « Sans Patron » (Exécution sans démon)

La plupart des moteurs de workflow nécessitent un ordinateur central (un démon) pour surveiller la cuisine 24h/24 et 7j/7. Si le patron plante, la cuisine s'arrête.
OxyMake est différent. C'est comme une équipe de cuisiniers indépendants qui peuvent entrer et sortir de la cuisine à tout moment.

• Revendication coopérative : Si deux cuisiniers essaient de saisir la même marmite, ils utilisent un protocole de poignée de main poli pour décider qui cuisine.
• Aucun point de défaillance unique : Si un cuisinier part ou si son ordinateur plante, les autres prennent simplement le relais. Vous n'avez pas besoin d'un gestionnaire central pour maintenir la cuisine en marche.

4. Le « Traducteur Universel » (Exécution polyglotte)

Dans une cuisine normale, vous pourriez être contraint d'utiliser un seul type de couteau ou un seul langage. OxyMake est polyglotte.

• Vous pouvez écrire la recette en TOML (un format de texte simple et propre), qui est facile à lire pour les humains et à comprendre instantanément pour les ordinateurs.
• Mais la cuisine réelle peut se faire en Python, R, Shell scripts ou Julia. OxyMake ne se soucie pas de la langue parlée par le cuisinier ; il transmet simplement les ingrédients et récupère le plat fini.

5. Le « Registre Honnête » (Reproductibilité)

OxyMake tient un journal strict et immuable (un fichier de verrouillage appelé ox.lock).

• Il enregistre exactement quels ingrédients ont été utilisés, ce que disait la recette et quel était le goût final du plat.
• Même si vous revenez dans cette cuisine cinq ans plus tard, sur un ordinateur complètement différent, OxyMake peut regarder le journal et dire : « Oui, si nous suivons exactement ce chemin, nous obtiendrons exactement le même résultat. »
• Il utilise même les mathématiques formelles (TLA+) pour prouver que son « protocole de poignée de main » pour les cuisiniers est sûr, garantissant que deux cuisiniers ne cuisinent jamais accidentellement le même plat ou ne se gênent pas.

Le Compromis : Vitesse vs Sécurité

L'article est très honnête sur un inconvénient :

• Démarrage à froid (Cold Start) : La toute première fois que vous lancez une recette, OxyMake est légèrement plus lent que les anciens moteurs car il doit « goûter » (hacher) chaque ingrédient pour construire ses empreintes.
• Exécution à chaud (Warm Run) : Mais une fois qu'il a fait cela, la deuxième fois que vous lancez la recette (ou si vous la lancez sur un autre ordinateur), il est beaucoup plus rapide et bien plus fiable. Il saute l'étape de la cuisine si les empreintes correspondent, là où les anciens moteurs pourraient être confus par les horodatages et tout recuire.

Résumé

OxyMake est un moteur de workflow qui arrête de deviner en fonction des horodatages et commence à vérifier le contenu réel de vos données. Il est construit avec un langage moderne et rapide (Rust), n'a pas besoin d'un patron central pour fonctionner, et tient un registre parfait et auditable de tout ce qu'il fait. Il échange un peu de temps de configuration initial contre des gains massifs en vitesse, en sécurité et en fiabilité lorsque vous exécutez vos flux de travail de manière répétée.

Résumé technique

Résumé Technique : OxyMake

Problématique

Les moteurs de workflow dans la lignée de « Make » (ex. GNU Make, Snakemake, Nextflow) reposent historiquement sur le temps de modification des fichiers (mtime) comme proxy pour détecter les changements de contenu. L'article soutient que cela constitue un « proxy fuyant » qui échoue de deux manières critiques :

1. Réexécutions fantômes : Des opérations telles que git checkout, des copies d'arborescence ou des restaurations de sauvegardes réécrivent le mtime sans changer le contenu des fichiers, forçant une réexécution inutile.
2. Réutilisation obsolète : Inversement, si le contenu d'un fichier de sortie est obsolète mais que son mtime paraît plus récent que celui de ses entrées (en raison d'un décalage d'horloge ou d'une restauration), le moteur réutilise silencieusement la sortie incorrecte.

Bien que Snakemake 7 atténue les réexécutions fantômes en enregistrant la provenance par sortie (code, paramètres, ensemble d'entrées), cet enregistrement est lié à un arbre de travail unique. Il ne peut pas voyager d'une machine à l'autre, entre des caches partagés, ni détecter une corruption sur disque où les octets changent sans mise à jour des métadonnées.

Méthodologie

OxyMake est un moteur de workflow en Rust, sous forme de binaire unique, qui remplace le proxy mtime par un mise en cache adressable par le contenu.

Principes de conception fondamentaux

1. Clés adressables par le contenu : La clé de cache pour une tâche est un hachage BLAKE3 de la source de la règle, des hachages de contenu des entrées, des paramètres, de la spécification de l'environnement et de la plateforme. Cette clé est une fonction pure des entrées déclarées.
2. Architecture à trois graphes :
   • RuleGraph (Logique) : Règles abstraites avec jokers (wildcards) non résolus.
   • JobGraph (Physique) : DAG entièrement résolu et optimisé avec des tâches concrètes.
   • ExecGraph (Runtime) : Annoté avec l'état en direct, les métriques et les journaux.
3. TOML Déclaratif : Les workflows sont définis en TOML, garantissant une parcabilité statique et évitant la surcharge d'exécution dynamique des DSL Python (comme Snakemake).
4. Exécution sans démon : Le moteur fonctionne sans démon central. Il utilise un protocole coopératif de revendication/récupération pour les sessions concurrentes, où l'état est persisté dans une base de données SQLite locale (.oxymake/state.db).
5. Spécification Formelle : Les invariants de sécurité inter-sessions (ex. empêcher deux sessions de revendiquer la même tâche) sont spécifiés en TLA+ et vérifiés par modèle via le vérificateur de modèle TLC. Cela traite la classe de danger « Concurrent State Transitions Across independently-Failing Peers » (CSTAFP).

Modèle d'exécution

OxyMake supporte un spectre de modes d'exécution :

• Shell/Run/Script : E/S standard basées sur les fichiers.
• Call : Références de fonctions pures (ex. fonctions Python) où OxyMake gère les E/S, permettant le passage de données en mémoire entre les tâches sur des exécuteurs supportés (ex. Ray).

Le moteur est « convergent » : ox run garantit que les sorties existent plutôt que de simplement lancer des tâches. Il gère l'invalidation transitive ; si un fichier intermédiaire est supprimé, le pré-scan du cache détecte l'absence et déclenche une reconstruction de toutes les tâches dépendantes en aval.

Contributions Clés

L'article liste sept contributions spécifiques :

1. Mise en cache adressable par le contenu : Élimine les réexécutions fantômes pour les entrées déclarées et supporte la cascade transitive lors de la suppression. Inclut un chemin rapide mtime+hash pour la performance.
2. Implémentation en Rust : Un binaire unique lié statiquement (14,9 Mo) avec un résolveur par rétro-chaînage utilisant la recherche de motifs précompilés, atteignant une résolution de DAG en moins d'une seconde.
3. Concurrence formellement spécifiée : Les invariants de sécurité inter-sessions sont spécifiés en TLA+ et vérifiés par modèle, plutôt que de s'appuyer uniquement sur des tests.
4. Architecture à trois graphes : Sépare la définition des règles, les plans résolus et les traces d'exécution, s'alignant sur les principes FAIR (Trouvable, Accessible, Interopérable, Réutilisable).
5. Fichier de verrouillage de reproductibilité (ox.lock) : Un plan de référence haché par le contenu permettant une redérivation exacte des graphes de tâches des années plus tard.
6. Interface lisible par machine : Flux d'événements NDJSON structurés et approbation de porte programmatique pour l'intégration d'outils en aval.
7. Exécution polyglotte : Supporte les modes shell, appels en interne (in-process) et scripts avec capacités de passage de données en mémoire.

Résultats et Évaluation

Des expériences ont été menées sur un Apple M4 Max (16 cœurs, 128 Go de RAM).

• Vitesse de résolution du DAG : OxyMake résout un DAG de 10 000 tâches en 69 ms, contre 2,31 s pour Snakemake 7.32.4 (une accélération de 33,3×). Cela est attribué aux motifs regex précompilés et à l'absence de surcharge de l'interprète Python.
• Performance à froid (End-to-End) : Lors d'un premier exécution (cold run), OxyMake est plus lent (1,25–2,3×) que Snakemake. L'article attribue cela au coût du hachage des entrées et de l'écriture des magasins adressables par le contenu.
• Performance de réexécution à chaud (Warm) : Sur les réexécutions à cache chaud (reconstruction sans opération), OxyMake est 7,54× plus rapide que Snakemake (372 ms contre 2,81 s pour 10 000 tâches). Même avec une vérification complète du contenu (--cache-validation=hash), il reste 4,02× plus rapide.
• Robustesse de l'adressage par le contenu : Dans un test de « git checkout » où le mtime a été perturbé mais le contenu est resté identique :
  • Snakemake 7.32.4 a réexécuté 0 tâche (grâce à ses enregistrements de provenance).
  • L'ancien mode pur mtime d'OxyMake a réexécuté 6 667 tâches (le rayon complet en aval).
  • Le mode actuel mtime+hash et le mode hash d'OxyMake ont réexécuté 0 tâche.
• Scalabilité : Le temps de résolution évolue de manière quasi linéaire avec le nombre de tâches (environ 6,6 µs/tâche ajoutée pour chaque augmentation de 100x du nombre de tâches).
• Empreinte mémoire : Le pic de mémoire de l'orchestrateur d'OxyMake (90,7 MiB) est 2,04× plus petit que celui de Snakemake (184,7 MiB) sur de grands runs.

Signification et Revendications

L'article positionne OxyMake comme une évolution rigoureuse du paradigme Make, privilégiant la correctitude et la reproductibilité plutôt que la vitesse brute à froid.

• Correctitude plutôt qu'heuristique : En remplaçant le mtime par le hachage de contenu, OxyMake garantit que la décision de mise en cache est une fonction pure des entrées déclarées, survivant aux remous du système de fichiers et permettant la portabilité du cache entre des machines de même plateforme.
• Rigueur formelle : L'utilisation de TLA+ pour spécifier et vérifier par modèle les invariants de sécurité inter-sessions est une caractéristique distinctive, traitant les dangers de concurrence que les tests seuls ne peuvent couvrir.
• Conformité FAIR : OxyMake cible explicitement les couches « Orchestration » (L2) et « Trace d'exécution » (L3/L4) de l'échelle de reproductibilité FAIR, déléguant le « Substrat » (L1) à des gestionnaires de paquets externes (ex. Guix, Nix) plutôt que de tenter d'absorber ce contrat.
• Compromis honnêtes : Les auteurs reconnaissent explicitement que la comptabilité adressable par le contenu impose une pénalité sur les exécutions à froid. Le moteur échange une certaine capacité de débit initiale contre la capacité de servir efficacement les réexécutions à chaud et de fournir des décisions de reconstruction auditables et portables.

L'article conclut qu'OxyMake est un « moteur de workflow en Rust sous forme de binaire unique » qui combine avec succès le paradigme de rétro-chaînage avec l'ingénierie moderne, offrant une alternative déterministe et performante pour les workflows scientifiques où la reproductibilité et la portabilité du cache sont primordiales.