Aller au contenu

03. Spécification de la Gestion de l'État : Découplage Total (Stateless Delivery)

Navigation : Documentation > 03. Gestion de l'État & Persistance

Sommaire

  1. Principe de Séparation Code / Données
  2. Standards d'Emplacements par Système d'Exploitation
  3. Linux et macOS : Spécification XDG Base Directory
  4. Windows : Standards AppData et ProgramData
  5. Prise en Charge des Applications Portables Spécifiques
  6. Sauvegarde Déclarative et Restauration d'État lors d'un Rollback (State Snapshots)
  7. Déclaration dans parts/package.toml
  8. Mécanisme de Snapshot & Restauration

1. Principe de Séparation Code / Données

erable applique un modèle de découplage strict entre les binaires applicatifs et les données de session de l'utilisateur.

Espace Immuable (Géré par erable)          Espace Utilisateur (Géré par l'OS)
~/.erable/packages/ripgrep/14.1.0/   ───X───>   ~/.config/ripgrep/ (Linux/macOS)
[Strictement en Lecture Seule]                  %APPDATA%/ripgrep/ (Windows)

  1. Immutabilité du Store de Paquets :
    Le répertoire ~/.erable/packages/<pkg>/<version>/ est traité en lecture seule dès la fin de l'extraction. Aucun fichier de données, de session, d'historique ou de configuration dynamique n'y est créé ou conservé.

  2. Survie aux Écritures Atomiques (Safe Saves) :
    Les logiciels modernes sauvegardent leurs configurations en écrivant dans un fichier temporaire puis en appelant rename() ou ReplaceFile(). En déléguant le stockage aux répertoires natifs de l'OS plutôt qu'à des liens symboliques ou jonctions fragiles, les données utilisateur ne subissent aucune rupture de synchronisation lors des mises à jour applicatives.

2. Standards d'Emplacements par Système d'Exploitation

2.1 Linux et macOS : Spécification XDG Base Directory

Le gestionnaire et les scripts normalisés orientent les applications vers les standards XDG :

  • Configurations utilisateur : $XDG_CONFIG_HOME (défaut : ~/.config/<app>).
  • Données persistantes : $XDG_DATA_HOME (défaut : ~/.local/share/<app>).
  • États et journaux : $XDG_STATE_HOME (défaut : ~/.local/state/<app>).
  • Caches temporaires : $XDG_CACHE_HOME (défaut : ~/.cache/<app>).

2.2 Windows : Standards AppData et ProgramData

  • Configurations itinérantes et préférences : %APPDATA%\<app> (AppData\Roaming).
  • Données locales et caches volumineux : %LOCALAPPDATA%\<app> (AppData\Local).
  • Données machine partagées : %ProgramData%\<app>.

3. Prise en Charge des Applications Portables Spécifiques

Pour les applications qui ne respectent pas nativement ces standards et cherchent à écrire à côté de leur propre binaire :

  • Le script normalisé post_install.nu configure les variables d'environnement officielles de redirection supportées par l'outil (ex: CONF_DIR, APPDATA, TOOL_HOME).
  • Le contexte typé $ctx injecté dans les scripts fournit directement les chemins standardisés de l'OS hôte sans nécessiter de calcul de chemin manuel.

4. Sauvegarde Déclarative et Restauration d'État lors d'un Rollback (State Snapshots)

Bien que les données applicatives résident dans les répertoires natifs de l'OS (~/.config ou %APPDATA%), une mise à jour majeure d'un outil (ex. passage de v1 à v2) peut migrer irréversiblement une base de données locale (SQLite, schéma JSON).
Un retour arrière vers v1 via erable rollback risquerait alors de faire planter v1 incapable de lire le schéma de données plus récent.

4.1 Déclaration dans parts/package.toml

Le manifeste peut déclarer explicitement les répertoires de données à sécuriser : 

[state]
backup_before_upgrade = true
data_dirs = ["$ctx.os_vars.appdata/myapp"]

4.2 Mécanisme de Snapshot & Restauration

  1. Sauvegarde Préventive : Lors d'une mise à jour de version, erable archive l'état de v1 dans ~/.erable/snapshots/<pkg>/<v1>.tar.zst.
  2. Restauration Associée : L'option --restore-state lors du rollback restaure conjointement le binaire antérieur et sa base de données compatible : 
    erable rollback <pkg> --restore-state