capa.config¶
Config IO and validation surface. :class:ConfigDocument tracks
where a draft came from (file path, inline vs external hardware /
method); the validation pipeline turns it into a frozen
:class:~capa.experiment.config.ExperimentConfig.
Narrative guides:
- Configuration overview — the four config kinds and how they compose.
- Experiment YAML, Hardware TOML, Method TOML.
- Validation and problems —
the :class:
ConfigProblemtaxonomy.
capa.config ¶
Config IO and validation surface.
ConfigDocument is the source-tracking layer — it knows what file the
draft came from, what format it was, and whether hardware/method were
inline or external. Distinct from
:class:~capa.experiment.config.ExperimentConfig, which is the
validated, frozen runtime object.
The validation pipeline (validate) and the ConfigProblem shape
layer on top.
ConfigDocument
dataclass
¶
ConfigDocument(
experiment_path: Path | None = None,
hardware_path: Path | None = None,
method_path: Path | None = None,
experiment_format: _StructuredFormat | None = None,
hardware_format: Literal["toml"] | None = None,
method_format: Literal["toml"] | None = None,
hardware_mode: Literal[
"external", "inline"
] = "external",
method_mode: Literal[
"external", "inline", "none"
] = "none",
experiment_payload: dict[str, Any] = dict(),
hardware_payload: dict[str, Any] = dict(),
method_payload: dict[str, Any] | None = None,
)
In-memory representation of a setup's on-disk layout.
Payloads are raw dict[str, Any] so mid-edit invalid state can
live here without fighting frozen Pydantic models. Promote
to :class:~capa.experiment.config.ExperimentConfig via
:meth:build_config at save / apply / validate boundaries.
Convention: experiment_payload never contains hardware or
method keys — those are tracked separately so save() can route
them per-mode. :meth:build_config re-inlines them before
validation.
load
classmethod
¶
Open an experiment YAML/TOML; resolve hardware/method refs.
Mirrors :meth:ExperimentConfig.load's file-ref rules: when
hardware: or method: is a string, treat it as a path
relative to the experiment file's directory. The presence /
absence of those refs determines hardware_mode /
method_mode.
Source code in src/capa/config/document.py
load_hardware_only
classmethod
¶
Open a bare hardware TOML; produce a minimal experiment payload.
Used by the Setup tab when the operator wants to author hardware in isolation. The experiment payload is left empty; the Setup tab fills in operator / sample / procedure stubs as the operator edits.
Source code in src/capa/config/document.py
composed_payload ¶
Re-inline hardware / method into a single experiment dict.
The returned dict is what :class:~capa.experiment.config.ExperimentConfig
:meth:model_validate expects: a single mapping with hardware
as a nested mapping and method either nested, absent, or
nested-from-an-inline-method. Source-path bookkeeping is
re-attached as the (excluded-from-serialisation) fields on the
model so callers that still go through :meth:load see the same
hardware_source_path / method_source_path they always did.
Source code in src/capa/config/document.py
build_config ¶
Validate payloads into an :class:ExperimentConfig.
Local import to break the circular dep:
capa.experiment.config imports nothing from capa.config;
this module imports from capa.experiment.config.
Source code in src/capa/config/document.py
save ¶
Atomic multi-file save back to the loaded paths.
For each target file: write <path>.tmp in the same directory,
then os.replace() into place. On any failure, delete already-
written .tmp files. Original files remain intact when any
member of the save set fails.
Pre-condition: every target path must already be set (use
:meth:save_as for first-time writes).
Source code in src/capa/config/document.py
save_as ¶
Save to a new layout; updates self in place on success.
Layout transitions (inline ↔ external for hardware / method) are
applied here; the document does not silently change them on
:meth:save.
Source code in src/capa/config/document.py
extract_hardware_inline_to_file ¶
Move inline hardware to an external file (without writing yet).
Only flips the mode and records the path; call :meth:save to
commit.
Source code in src/capa/config/document.py
inline_hardware_from_file ¶
Inline a currently-external hardware file (without writing yet).
Source code in src/capa/config/document.py
SaveError ¶
SaveError(
message: str,
*,
failed_path: Path | None = None,
rolled_back_paths: tuple[Path, ...] = (),
)
Bases: CapaError
Raised when an atomic multi-file save fails.
The exception carries the path that failed and any partial-write paths that were rolled back so callers can present an actionable message ("hardware file save failed; experiment file unchanged").
Source code in src/capa/config/document.py
SourceLayout
dataclass
¶
SourceLayout(
experiment_path: Path | None,
experiment_format: Literal["yaml", "toml"] | None,
hardware_path: Path | None,
hardware_format: Literal["toml"] | None,
hardware_mode: Literal["external", "inline"],
method_path: Path | None,
method_format: Literal["toml"] | None,
method_mode: Literal["external", "inline", "none"],
)
Target layout passed to :meth:ConfigDocument.save_as.
Each field maps onto the same-named field on :class:ConfigDocument.
Methods that mutate layout (e.g. extract-to-file) compose a new
SourceLayout and call save_as.
ConfigProblem ¶
Bases: BaseModel
One validation finding addressable by (section, path).
severity controls colour and whether Apply & Connect stays disabled
(any "error" blocks). code is a stable identifier
("channel.missing_source_device") so the UI can offer code-keyed
quick fixes; message is the operator-facing prose.
path is the tuple address from the section's root model — e.g.
("devices", 2, "params", "port") points at the third device's
params.port field. source_file indicates which file would
carry the fix (hardware TOML vs experiment YAML) so the Save dialog
can show the right path next to the problem.
fix_label
class-attribute
instance-attribute
¶
Short imperative label for a one-click fix ("Choose a device").
Optional — only emitted by checks that have a canonical fix.
validate_live_async
async
¶
Async-native Layer 5 driver for the Setup tab's Check Hardware button.
Re-runs Layers 1–4 first (they're cheap and a failed schema means we can't compose a config to hand to the live layer), then runs Layer 5 concurrently. Returns the merged list ordered by severity.