Partie 12

Reconstruire votre environnement, pas votre mémoire

L’automatisation la plus précieuse n’est pas toujours une tâche métier. Parfois, c’est la possibilité d’arriver sur un nouvel hébergement, déposer un petit Core, exécuter une recette explicite et retrouver les outils et habitudes auxquels vous faites confiance.

Votre environnement est une recette plus de l’état

Modules installés, paquets d’interface, scripts de démarrage et préférences décrivent le comportement du terminal. Les fichiers du projet et les bases de données sont une autre couche d’état. Séparer ces idées simplifie fortement migration et récupération.

Notez ce qui doit être recréé automatiquement et ce qui doit être restauré depuis une sauvegarde. Une recette d’installation décrit les outils et des valeurs par défaut sûres ; elle ne doit pas transporter discrètement des données applicatives ou des identifiants vers un nouvel hôte.

Avant d’écrire la recette, inspecter l’environnement que vous utilisez déjà

core donne l’image compacte Core/UI/modules, install -l liste modules et paquets installés, include montre le stockage des paquets d’interface et upgrade -c vérifie les versions sans écrire.

Cet inventaire sépare « je crois avoir besoin de ces outils » d’une véritable liste reproductible. Retirez les vieilles habitudes avant de les figer dans l’automatisation de l’installation.

core

install -l

include

upgrade -c

`setup.lil` est un bootstrap unique, pas un script de démarrage permanent

Le Core actuel détecte un setup.lil régulier à côté de lil.php, l’exécute après autorisation lorsque nécessaire et ne le supprime qu’après réussite de tous les statements. Si l’Installer complet manque, Core peut le récupérer et reprendre l’opération d’installation initiale.

Gardez l’installation explicite. Installer plusieurs modules en un seul appel à install reste compact et lisible ; une version exacte avec -v convient lorsqu’une recette doit reproduire volontairement un état précis. Les mots de passe, clés privées et identifiants de base de données propres au projet n’ont pas leur place dans ce fichier.

install help history upgrade dir pwd md mf edit find stat hash run

`autoload.lil` sert aux petites actions récurrentes au début d’une session

run vérifie autoload.lil une fois par session autorisée et ne le supprime pas. Il convient donc à de petits checks ou à la préparation d’environnement qui doivent se répéter, pas à une installation unique.

upgrade -auto check est un bon exemple : il gère un petit bloc dans autoload.lil et vérifie les updates une fois par session. L’update automatique est une politique plus forte et reste opt-in ; sur un environnement important, vérifier, relire puis mettre à jour est souvent préférable.

upgrade -auto check

upgrade -info

La reproductibilité exige de savoir quelle liberté vous avez choisie

install <mod> sélectionne la version publique compatible actuelle ; install <mod> -v <ver> demande un numéro publié précis. Les deux formes respectent toujours la génération Core active et les dépendances du module.

Les anciens jalons de la génération 1 restent visibles à titre historique et ne sont plus des cibles d’installation. La version prise en charge est la version actuelle. À partir de la prochaine publication, les versions numérotées ont vocation à rester disponibles comme cibles exactes, sauf retrait explicite.

install hash -i

install hash -v 1.1.3

L’interface du navigateur est une couche de paquets, pas l’environnement d’exécution des commandes

include gère des paquets CSS/JavaScript composables comme lil, hotkeys et code. Le mode session est temporaire ; -s crée une composition persistante dans .lil.css et .lil.js.

Cette séparation aide lors d’un changement d’hôte : les modules PHP peuvent être corrects même si votre UI préférée manque. Reconstruisez d’abord les fonctions, puis la présentation. Si la couche interface est confuse, kill -include réinitialise uniquement cette couche sans supprimer Core.

include -l

include lil -i

include -lil -s

Une recette d’installation n’est terminée qu’après un test dans un environnement jetable

La meilleure preuve est une installation propre : déployez un Core neuf, exécutez la recette, puis comparez core, install -l et upgrade -c avec l’environnement que vous vouliez reproduire.

Ce test révèle les dépendances invisibles : commande installée à la main il y a des mois, paquet d’interface oublié ou extension disponible sur un hôte et absente sur un autre. La reproductibilité se découvre en reconstruisant, pas en l’affirmant.