Scaffold
One command picks a template and fills in the metadata — the directory, class, and files are created for you.
Salpa CLI · for developers
Scaffold a real node in seconds
pip install salpa-cli
Salpa CLI turns one command into a complete node package: metadata, code, an isolated environment, sample data and tests. You start from a runnable skeleton built on the same templates our own nodes use, not a blank file.
Apache-2.0 · Python 3.9+ · macOS · Linux · Windows
salpa new, salpa validate, pixi run test, then salpa smoke.The commands
From an empty directory to the app on your machine.
salpa new- Scaffold a package from a template — single node, or several nodes sharing one environment.
salpa add- Name the packages your code needs. It finds them in your channels, writes them, and narrows the platforms you claim to the ones that can actually run them — and nothing is written unless every name resolves and the solve passes.
salpa platforms- Measure which platforms the package can really declare, instead of trusting the list: each is reported as right, wrong, could be added, or correctly left out. With --solve it confirms they resolve together.
salpa dev- The guided loop. It shows what is still outstanding and runs the next step for you — metadata, dependencies, the environment, the checks, and the handover to the app.
salpa validate- Check a package against the install and registration contract, before you load it into the app.
salpa env- The package’s own isolated environment — see what exists, build it, remove it. This is what its tests and salpa smoke run in.
salpa smoke- Run the node on its own sample data — and again with that input taken away, where reporting success would be the failure.
salpa push- Put the package into the Salpa app on this machine, ready to install from the Marketplace. Re-run after an edit to refresh it.
salpa unpush- Take it back out again. Your own directory is left exactly as it is.
salpa docs- Read the node-authoring guides bundled with the CLI, offline.
validate is a static check: it reads the package and tells you whether it satisfies the install and registration contract. Running the science is what the tests, and the app, are for. push talks to the Salpa app on your own machine: nothing is uploaded, and nothing is published.
One command, a complete package
Answer a few prompts; the package it writes already validates.
meta.toml- Package metadata — name, category, discovery hashtags, ports.
core.py- The science: pure Python you can unit-test on its own.
node.py- A thin wrapper — options + an execute() that calls your core.
pixi.toml- The package’s dependencies, which Salpa installs into an isolated environment.
demo_data/- A sample input, so salpa smoke can run the node from the start.
README.md- A ready-to-fill readme — what the node does, its inputs and outputs, and how to run it.
tests/- A starting test suite for the core and the node.
The science lives in core.py; the app integration stays a thin wrapper, the two-level shape every Salpa node uses.
$ salpa new protein-analyzer Template: 1. individual-node — one node, its own pixi env (the default) 2. multi-node-package — several related nodes sharing one pixi env, chained Choose [1/2] (1): 1 … ✓ validate: no findings (structure, naming, environment) Next steps: 1. Edit meta.toml — description, category, hashtags, license. 2. Put the science in core.py; keep node.py a thin wrapper. 3. salpa add <package> ... (dependencies — and it narrows `platforms` to what can actually run them) 4. pixi run test (builds the test env on first run; core + node tests) 5. salpa smoke protein_analyzer (does it actually run? needs the test env above) 6. salpa push protein_analyzer (into your running Salpa app, ready to install)
When one node isn’t enough
Several nodes, one environment
A pipeline is usually a few related steps. The second template scaffolds them together — one shared environment at the root, one directory per node — so they stay in step instead of drifting apart.
salpa validate checks the whole package, both nodes’ tests run in it, then salpa smoke runs each node on its own sample data.Dependencies, without the guesswork
Name it. Salpa works out where it runs.
A dependency is two claims: the package your code needs, and the platforms you say your node supports. salpa add makes both at once — it finds the package in your channels, writes it, and narrows platforms to the ones that can actually run it, with a reason recorded for every one it drops. If any name fails to resolve, or the solve fails, nothing is written at all.
Or be led through it
One command that knows what’s left
salpa dev shows the whole package in one panel — what is done, what is outstanding, and what each step would do — and runs the next one for you. It reads the state fresh every time, so the checklist is the menu rather than a list you keep in your head. Nothing is guessed: whether your node actually runs, and whether the app has it, are marked not checked until something checks them.
From your editor to the canvas
One command puts it in the app
salpa push hands your package to the Salpa app running on your machine. Nothing is uploaded, nothing is published: it is a local handover, and the package appears in the Marketplace ready to install.
salpa push shows what it will move before it moves it — then the package is on the shelf, and salpa unpush takes it back out.- Local, not remote
- It targets the app on this machine over its own local interface. Nothing leaves your computer.
- Stops at the shelf
- The package becomes available to install; the install itself stays a click you make in the app, running the same installer every package goes through.
- Edit and re-push
- Your directory is the source, so re-running after a change refreshes what the app offers — no copying, no second copy to keep in step.
- Reversible
- salpa unpush removes it again and leaves your own files untouched, exactly as you left them.
Salpa has to be running: the CLI asks the app where its files live rather than guessing, so the same command works whether you run Salpa from a checkout or the desktop app.
Watch it land in the app
The same handover, end to end.
salpa new scaffolds the package, validate confirms it and push hands it over; then the app answers: the package on the Marketplace shelf, installed in a click, its nodes in your library. salpa unpush takes it back off the shelf.Scaffold, write, check, push
The CLI handles the boilerplate, so your time goes to the science.
Write the science
Your logic goes in core.py — plain Python, testable without the app — and a thin node.py exposes it as a node. salpa add names the packages it needs and works out where they can run.
Check, test, run
salpa validate checks the package will install and register; its tests run in the node’s own environment; salpa smoke actually runs the node. salpa dev walks all of it in order if you would rather be led.
Push it in
salpa push puts the package into the Salpa app on your machine, ready to install from the Marketplace.
Build your first node.
pip install salpa-cli, then salpa new. The full node-authoring guide is in the Salpa docs.