96. The live image opens a setup that asks what tacid install takes

Context

The live image opened tacid on its first console. That is the interface of an installed machine, and on the live image it could not install anything. What it showed was a paragraph telling the person to switch to another console and type tacid install with six flags, one of which was a /dev/disk/by-id/… path they had to find with ls. Someone who boots a medium expects what Ubuntu Server, Debian and Fedora give them: questions, one screen at a time, and a disk erased only after they have seen the plan and said yes.

tacid install is a good engine and a bad first contact. It is what a script, a test or a fleet should run. Nobody should have to start there.

Decision

The live image opens tacid setup on its first console, as root. It asks eight questions, then shows one review. Every answer is a flag tacid install takes, and both drive the same installation code.

The screens are: keyboard, network, disk, encryption, you (name, machine name, user name, password), SSH (keys imported from GitHub, GitLab or Launchpad and shown by fingerprint), time zone and language, and what kind of machine (workstation or server, and how much the agent may do). After them comes the review: the plan, what stands in the way, and y to erase.
The setup is a state machine (tui/setup.rs) and a pure view (tui/setup_view.rs). Neither touches the machine. A runner (tui/setup_run.rs) carries out what they ask: loadkeys, the keeper for Wi-Fi and for the installation, the daemon for keys and the build. A test walks the whole setup and proves its Choices equal those built from the flags a script would pass.
installer.rs is the one place that turns choices into an installation. It composes the installation and lists what stands in the way (prepare), summarises it, builds the keeper’s request (params), fetches keys, builds the system, installs, and says what was installed. tacid install and the setup are two faces of it.
The keyboard comes first, and it reaches the console at once. The layout is the one thing nothing can detect, and the disk passphrase and the password are typed on it. The setup runs loadkeys when one is chosen, but only on a virtual console. Over a serial line or SSH, the terminal at the other end has its own layout. It is the setup’s to run, not the stem’s: the setup is already root at the live image’s console, and the stem’s vocabulary is for changing machines, not for making an installer usable.
The boot medium is never offered. Disk facts now carry each disk’s /dev/disk/by-id path and whether something on it is mounted. A disk in use is listed as not offered, with the reason. A script that names it anyway is refused in prepare.
Root, at the console, from the start. The keeper installs only for uid 0 at the console. The image’s own user has passwordless sudo, so tty1 runs sudo tacid setup. It is not exec’d: Ctrl+C drops to a shell with a line explaining how to come back. A setup that asked eight questions and was refused at the end would be worse than one that asked for root first.
Escape goes back, Ctrl+C leaves. On the fifth question, Escape means the fourth. The interface’s own Escape-quits is the wrong reflex here.

Consequences

A person who boots the image sees a keyboard list and can install without reading anything.
The setup offers a curated list of about twenty keyboards and twenty languages. Anything else is tacid install --keyboard … --locale …, which takes any XKB layout and any glibc locale.
--autonomy is now a flag of tacid install, because the setup asks for it and the two faces take the same answers.
A plan printed at a terminal is followed by a typed erase. The --yes on the command line is easy to have typed for the wrong disk.
The interface on the image’s other consoles names sudo tacid setup first, and the command second.

Alternatives rejected

Make the interface itself install. The interface is a conversation with a running machine. An installer is a form with a review. Putting the second inside the first would have made both worse and given a person two ways to be half-way through an installation.
A shell script with dialog. It would be a second implementation of every check the installer makes, and it would drift from the first. The first time the two disagreed, a person would install a machine the script had said was fine.
Autodetect the keyboard. The kernel reports scancodes, not legends, so there is nothing to detect. Asking is the only honest answer, and asking first is the only useful place for it.