Salpa CLIFor developers

Scaffold a real node in seconds

Salpa CLI turns one command into a complete node package — metadata, code, an isolated environment, and tests. You start from a runnable skeleton built on the same templates our own nodes use, not a blank file.

$ pip install salpa-cli

Apache-2.0 · Python 3.9+ · macOS · Linux · Windows

A real terminal session — salpa new, salpa validate, pixi run test, then salpa smoke.
Developer experience

Turning your code into a node is the easy part.

Making that easy has been core to Salpa from the start. A small, templated wrapper turns plain Python into a visual workflow node — no framework to learn, and almost no boilerplate to write by hand. The CLI takes it one step further, scaffolding the whole package so you begin from something that already runs and tests green.

  • salpa newScaffold a package from a template — single node, or several nodes sharing one environment.
  • salpa addName 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 — one solve, and nothing is written unless every name resolves.
  • salpa devThe 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 validateCheck a package against the install and registration contract, before you load it into the app.
  • salpa envThe package’s own isolated environment — see what exists, build it, remove it. This is what its tests and salpa smoke run in.
  • salpa smokeRun the node on its own sample data — and again with that input taken away, where reporting success would be the failure.
  • salpa pushPut the package into the Salpa app on this machine, ready to install from the Marketplace. Re-run after an edit to refresh it.
  • salpa unpushTake it back out again. Your own directory is left exactly as it is.
  • salpa docsRead 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 there is no hub involved.

From blank file to working package

One command, a complete package.

Pick a template, answer a few prompts, and get a package that already installs and tests green.

terminal — salpa new
# scaffold a new node package
salpa new protein-analyzer

Template:
  1. individual-node   one node, its own env
  2. multi-node-package several nodes, one shared env
Choose [1/2] (1): 1
Category: Cheminformatics
Hashtags: md, protein, analysis

✔ Created protein_analyzer/
  meta.toml  core.py  node.py  pixi.toml  README.md  tests/
scaffolded · pixi run test → 5 passed
  • meta.tomlPackage metadata — name, category, discovery hashtags, ports.
  • core.pyThe science: pure Python you can unit-test on its own.
  • node.pyA thin wrapper — options + an execute() that calls your core.
  • pixi.tomlAn isolated, reproducible environment for the node’s dependencies.
  • README.mdA ready-to-fill readme — what the node does, its inputs and outputs, and how to run it.
  • tests/A starting test suite so `pixi run test` is green from the first minute.

The directory is a proper Python package; the science lives in core.py and the app integration stays a thin wrapper — the two-level shape every Salpa node uses.

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 sync instead of drifting apart.

Two nodes, one shared environment — 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. One solve, and if any name fails to resolve nothing is written at all.

The manifest before and after, so the two lines that changed are the two you can see — and the platform list narrows itself rather than being taken on trust.
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.

Walk it with the arrow keys, or jump straight to a step. Editing your metadata this way changes the values and leaves every comment in the file exactly where you wrote it.
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.

The whole loop

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.

The CLI does the work in the terminal; the running app answers — the same package the CLI pushed, appearing in the Marketplace, installed, and running as nodes you can drop on a canvas.
The workflow

Scaffold, write, check, push.

The CLI handles the boilerplate so you spend your time on the science, not the setup.

Scaffold

One command picks a template and fills in the metadata — the directory, class, and files are created for you.

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 — you’ll have a runnable node package in seconds, salpa validate to tell you it will load, and salpa push to put it in the app. The full node-authoring guide is in the Salpa docs.