Everything that does work in PLESTY is a module, and there are three kinds:
What a module declares is the point: tools work from it without knowing the instrument or the measurement.
- A device's schemas are what its server checks every call against, what a client learns when it connects, and what its documentation is generated from — so the docs cannot drift from what the server accepts. Each operation also declares its kind (read, measure, move, configure…) and budget (how long it may take).
- An experiment's manifest is every setting it takes, typed and with
units — PLESTY Bench lays it out as a form. Its
setup.yamlnames its devices and the benches they run on. - An analyzer's schemas are what its inputs and outputs are checked against, and what every result it produces is labelled with.
One instrument, one repository
A module is a whole project: its own repository, version, documentation and
release. A powermeter is not a file in a lab's codebase — it is
plesty-pm100d, installable by anyone, at the version they choose. That is
what lets a bench install exactly the instruments it has, lets versions move
independently, and keeps a module installable long after the experiment it
was written for.
[tool.plesty] in pyproject.toml tells the platform which rules apply:
[tool.plesty]
module_type = "device" # device, analyzer, experiment or core
standard = "quantum" # left out: derived from the release version
The standard tightens as a module matures — pixel before 0.1.0, nebula
before 1.0.0, quantum from then on — see Quality Gates.
Every module shares the plesty namespace: the project plesty-pm100d is
imported as plesty.pm100d.
Read next
- Networking — how the modules of one measurement find each other.