Le déploiement Proxmox se faisait par vingt questions, l'une après l'autre, sans jamais voir le plan entier. Il a maintenant le même écran que QEMU/KVM — catalogue à gauche, plan à droite, totaux dessous — et une touche pour revenir aux questions. Il n'en redit rien : 690 lignes contre 1 340, tout le reste vient du socle commun. Ce que Proxmox a en propre est montré AVANT de lancer : le VMID, parce que l'hôte ne dit « déjà pris » qu'après avoir téléchargé l'image, et l'adresse qui s'en déduit sur un pont interne. Le stockage et le pont sont lus sur l'hôte, jamais devinés. L'icône 🗄 distingue l'entrée du menu de celle qui déploie ici même. --- EN --- Deploying on Proxmox meant twenty questions, one after another, never seeing the whole plan. It now has the same screen as QEMU/KVM — catalogue left, plan right, totals below — and a key to fall back to the questions. It repeats none of it: 690 lines against 1,340, everything else comes from the shared foundation. What belongs to Proxmox is shown BEFORE launching: the VMID, because the host only says "already taken" after downloading the image, and the address derived from it on an internal bridge. Storage and bridge are read from the host, never guessed. The 🗄 icon tells the menu entry apart from the one that deploys right here. Assisted-by: Claude Opus 5
4.4 KiB
TODO is an assistant robot to use ERPLibre
Execute it with ./script/todo/todo.py or make todo.
For a new project, copy todo_example.json to private/todo/todo_override.json | private/todo/todo_override_private.json and edit it.
The mail/ package is the mail client reachable from Assistant > Mail:
several IMAP/SMTP accounts, a local cache, and a Textual TUI. See
../../doc/EMAIL.md.
Where the code lives
todo.py carries the menus and the general helpers. Everything around a
single subject sits in its own file, and the whole thing is assembled by
mixins on the TODO class — one file, one subject, its header states its
boundary.
| File | What it owns |
|---|---|
todo.py |
the menus, the configuration, the general helpers |
qemu_menu.py |
the QEMU/KVM menu, the image catalogue, the statistics |
qemu_deploy.py |
deciding then running a deployment |
qemu_install.py |
the recipes run inside a VM |
qemu_manage.py |
lifecycle, disks, hardware, cleanup, addresses |
qemu_access.py |
SSH, tunnels, consoles, Android emulator |
proxmox_menu.py |
the same, on a REMOTE Proxmox VE host |
The two deployment forms — libvirt here, Proxmox over there — ask the same questions, so they share a foundation rather than each holding a copy:
| File | What it owns |
|---|---|
deploy_form_lib.py |
pure logic (sizes, plan, totals, spec), the shared CSS, the resource-row factory, the progress view |
deploy_form_plan.py |
the plan's gestures: overrides, locks, copies, renaming, free values |
qemu_deploy_form.py |
what QEMU/KVM adds: desktops, tools, branches, install profiles |
proxmox_deploy_form.py |
what Proxmox adds: host, storage, bridge, VMID, address |
A form inherits PlanMixin and provides three hooks: which presets each
resource offers, the name a VM would fall back to, and what a lock freezes.
test_todo_deploy_form_lib.py fails if a form redefines a gesture the
foundation already carries — that is what keeps the architecture from drifting
back into two copies.
TODO est un robot assistant pour utiliser ERPLibre
Exécutez-le avec ./script/todo/todo.py ou make todo.
Pour un nouveau projet, copiez todo_example.json vers private/todo/todo_override.json | private/todo/todo_override_private.json et modifiez-le.
Le paquet mail/ est le client courriel accessible depuis
Assistant > Courriel : plusieurs comptes IMAP/SMTP, un cache local, et un
TUI Textual. Voir ../../doc/EMAIL.fr.md.
Où vit le code
todo.py porte les menus et les aides générales. Tout ce qui tourne autour
d'un même sujet vit dans son fichier, et l'ensemble est assemblé par des
mixins sur la classe TODO — un fichier, un sujet, son en-tête dit sa
frontière.
| Fichier | Ce qu'il porte |
|---|---|
todo.py |
les menus, la configuration, les aides générales |
qemu_menu.py |
le menu QEMU/KVM, le catalogue d'images, les statistiques |
qemu_deploy.py |
décider puis exécuter un déploiement |
qemu_install.py |
les recettes exécutées DANS une VM |
qemu_manage.py |
cycle de vie, disques, matériel, nettoyage, adresses |
qemu_access.py |
SSH, tunnels, consoles, émulateur Android |
proxmox_menu.py |
la même chose, sur un hôte Proxmox VE DISTANT |
Les deux formulaires de déploiement — libvirt ici, Proxmox ailleurs — posent les mêmes questions : ils partagent donc un socle au lieu d'en garder chacun une copie.
| Fichier | Ce qu'il porte |
|---|---|
deploy_form_lib.py |
la logique pure (tailles, plan, totaux, spec), le CSS commun, la fabrique des rangées de ressources, la vue de progression |
deploy_form_plan.py |
les gestes du plan : surcharges, verrous, exemplaires, renommage, valeurs libres |
qemu_deploy_form.py |
ce que QEMU/KVM ajoute : bureaux, outils, branches, profils d'installation |
proxmox_deploy_form.py |
ce que Proxmox ajoute : hôte, stockage, pont, VMID, adresse |
Un formulaire hérite de PlanMixin et fournit trois crochets : les
préréglages de chaque ressource, le nom auquel une VM retombe, et ce qu'un
verrou fige. test_todo_deploy_form_lib.py échoue si un formulaire redit un
geste que le socle porte déjà — c'est ce qui empêche l'architecture de
retomber en deux copies.