Mathieu Benoit
9b5d7db2a7
Rapporté sur Arch : « pas l'écran de connexion, avec le guide qui dit de prendre pacman, comme sur ubuntu ». Ce n'était pas Arch — c'était Proxmox. La voie libvirt livre /etc/motd par le « write_files » de cloud-init, et « qm set » n'offre pas cela : AUCUNE VM déployée sur un hôte Proxmox n'avait de guide, quelle que soit sa distribution. Une troisième voie de livraison, par ssh une fois la VM debout, avec la MÊME source — « guide_files », qui connaissait déjà pacman. Le guide n'annonce le dépôt que s'il y sera : un guide qui promet ce qui n'existe pas est pire que pas de guide. Écrit sur la VM Arch de l'utilisateur pour le vérifier. --- EN --- Reported on Arch: "no login screen, with the guide telling you to use pacman, like on ubuntu". It was not Arch — it was Proxmox. The libvirt path delivers /etc/motd through cloud-init's "write_files", and "qm set" offers no such thing: NO VM deployed on a Proxmox host had a guide, whatever its distro. A third delivery path, over ssh once the VM is up, from the SAME source — "guide_files", which already knew pacman. The guide only announces the repository if it will be there: a guide promising what does not exist is worse than none. Written onto the user's Arch VM to check it. Assisted-by: Claude Opus 5 |
||
|---|---|---|
| .. | ||
| auto_ask.py | ||
| database_manager.py | ||
| deploy_form_lib.py | ||
| deploy_form_plan.py | ||
| kdbx_manager.py | ||
| logo_ascii.txt | ||
| migration_form.py | ||
| migration_stats.py | ||
| migration_status.py | ||
| migration_status_tui.py | ||
| proxmox_deploy_form.py | ||
| proxmox_menu.py | ||
| qemu_access.py | ||
| qemu_deploy.py | ||
| qemu_deploy_form.py | ||
| qemu_hardware.py | ||
| qemu_install.py | ||
| qemu_install_monitor.py | ||
| qemu_manage.py | ||
| qemu_menu.py | ||
| README.base.md | ||
| README.fr.md | ||
| README.md | ||
| source_todo.sh | ||
| textual_setup.py | ||
| todo.json | ||
| todo.py | ||
| todo_example.json | ||
| todo_file_browser.py | ||
| todo_i18n.py | ||
| todo_prefs.py | ||
| todo_telemetry.py | ||
| todo_upgrade.py | ||
| version_manager.py | ||
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.