Contribute a Module

PLESTY software comes in modules: one Python package each. A device module talks to one instrument, an experiment module runs a measurement across several devices, and an analyzer module turns what an experiment recorded into a result. The hub is where published modules live: their code under plesty/hub on GitLab, and the catalogue on hub.plesty.net that a lab searches and installs from.

A module you wrote reaches the hub in five steps. None of them needs anyone's approval until the last one, the review.

1. Scaffold it with plesty init

plesty is the command of plesty-sdk, PLESTY's development tool. plesty init creates a complete, empty module of the kind you name — package layout, tests, documentation pages and the CI pipeline — so your code goes into a structure every other module shares:

uv tool install plesty-sdk
plesty -d plesty-powermeter init device       # or: init analyzer, init experiment

The directory name becomes the package name: plesty-powermeter is what users install, plesty.powermeter what they import. plesty init also makes the first git commit, in your name if git knows it — set git config --global user.name and user.email first, or one of the gates will later refuse the push. Move your existing code into the generated files; Find or Scaffold walks through the result for a device, and Scaffold for an experiment.

2. Pass plesty check

plesty check runs the platform's quality gates: the automatic checks — formatting, types, tests, licences, documentation and more — that every hub module passes. plesty init installs it as a hook, so it also runs before every git push.

cd plesty-powermeter && uv sync
uv run plesty check

Fix what it reports until every gate passes. Quality Gates explains each gate and how to fix it.

3. Ask for a repository under plesty/hub

Modules are hosted in the PLESTY group on GitLab, sorted by kind: devices under plesty/hub/devices/<vendor>, analyzers under plesty/hub/analyzers, experiments under plesty/hub/experiments. You cannot create a project there yourself, so ask for one: open an issue in the governance project with the module's name, its kind, and the instrument or measurement it is for. You need a free GitLab account to open it.

Once the repository exists, you are given access to push branches to it.

4. Push it and open a merge request

A hub module keeps two long-lived branches: main, which holds only released versions, and exp, where finished work collects before the next release. Your code arrives on a branch of its own and enters exp through a merge request — GitLab's request to merge one branch into another, where the change is reviewed and the pipeline runs:

git remote add origin <the repository's URL, from its GitLab page>
git checkout -b feat/powermeter
git push -u origin feat/powermeter

Then open the merge request into exp from the link git push prints. Branch Discipline explains the branches and why nothing is pushed onto main or exp directly.

5. What happens after

• The pipeline runs on the merge request: the same gates as plesty check, plus the ones only CI runs (CI Pipeline). It must be green.
• A PLESTY maintainer reviews the merge request, and you answer the comments on it. When it is approved, it is merged into exp.
• Your first release merges exp into main and tags a version, which publishes the package to PyPI, the Python package index pip and uv install from (Publishing a Release).
• The module appears on the hub. hub.plesty.net lists it with its install line, and its documentation is published at docs.plesty.net/<module>/ — every lab can now install it from PLESTY Bench, the application on each lab PC.

Read next

The Contributor Guide has the details behind every step: the module layout, the standards the gates hold a module to, and the release process.