What an extension is

Everything in the default palette — MNE, PyTorch, scikit-learn, Hugging Face — runs inside BCILattice's own process, because we bundled it and vetted it together with the app. A extension is how you add a library we did not bundle, without touching that process at all.

  Settings › Extensions                  ~/.bcilattice/extensions/<id>/
   [Install] [Start] [Stop] ──spawns──▶  its own venv, its own server, its own port
                                          your library lives here, not inside BCILattice

  ML Suite palette
   your library ▾   Custom Code (your library)   ← the blocks it produced

Install a spec — a package name, a pin, a Git URL — and BCILattice creates a private Python environment for it, starts a small local server inside that environment, and introspects the library's public functions into palette blocks automatically. Nothing you write; the blocks, their ports and their settings come straight from the library's own type hints and defaults.

Bundled provider vs extension

Only one of these gets a process, a Start button, and a Settings page entry.

The palette itself does not visually separate them — an extension block sits in the canvas next to a bundled one and wires the same way. The difference only matters in Settings, and only because one of the two has a process to manage.

Cedalion: the free example

Cedalion — the IBS-Lab fNIRS/DOT toolbox — ships as an extension and only an extension: there is no in-process fallback and no bundled copy. Its blocks (Beer-Lambert conversion, motion correction, channel-quality metrics, DQR figures) exist once you install it from Settings › Extensions, and not before. It is free on every plan, because it is the extension mechanism's own demonstration — hiding it behind a paywall would hide the feature it is meant to show off.

Installing one

Where: Settings › Extensions.

Curated shelf vs any spec

Free plans install from the curated shelf below — 24 packages we resolved, tested and licence-checked ourselves. Pro and Enterprise can install any spec: a private index, a GitHub URL, a local path. That boundary is deliberate, not just commercial — the free tier only ever runs code we vetted, so the overwhelming majority of installs never touch a package nobody here has looked at.

Start, stop, restart

Each extension row in Settings shows Start / Stop / Logs / Re-introspect / Uninstall. Stopping a library that has gone into an infinite loop cannot be asked nicely — a stuck call cannot be interrupted — so Stop escalates automatically through progressively firmer signals, and a Force stop option appears while the graceful attempt is still in progress rather than only after it times out. Restart does both steps as one action. An engine survives an app restart in its own right — stopping one that was left running from a previous session works the same way as stopping one from the current session.

The curated shelf

Every entry below was actually resolved and installed during vetting — nothing here is a package that turns out not to install. Licences are read from package metadata, not assumed, and only permissive licences are curated; a GPL package can still be installed as a custom spec on Pro, but it is your call to make, not ours to recommend.

Already-bundled libraries never appear here twice — mne-nirs and pyriemann, for instance, look like they belong under fNIRS but ship with the app already, so their blocks already live under the MNE palette.

How a library becomes blocks

No one hand-writes an extension's blocks. Installing runs the library's own public functions and classes through an introspector, which reads their type hints, defaults and docstrings and emits the same kind of catalog row the bundled palette is built from — so an extension block gets a real inspector, a tooltip and typed ports the same way any other block does.

Ports vs settings

What ends up wireable versus what ends up a field follows one rule:

The result is a plain, inspectable catalog file — if the heuristic guesses a port wrong for a specific function, that is a text-file fix, not a code change.

Core vs advanced blocks

Introspection is deliberately greedy — it emits a block for every public callable it can classify. Cedalion alone yields 329. Shipping all 329 onto the front page would repeat the mistake the bundled catalog already made, so every generated block starts at advanced and stays out of the way.

An extension may then carry a small hand-written curated.yaml that promotes a handful of targets to core — giving each one a display name, a palette category, defaults and unit hints. Cedalion promotes 18, so a first-run fNIRS palette reads Cedalion SNIRF Reader, Cedalion Beer-Lambert, Cedalion Frequency Filter rather than cedalion.io.read_snirf and 328 siblings.

An extension with no curation file is still perfectly usable — all of its blocks simply live at advanced. The file is plain YAML, so you can write your own for a library you installed and give it the front page you want.

Custom Code, per extension

Every installed extension also gets its own Custom Code (your library) block — a Pro feature. Your snippet runs inside that extension's own environment, with the library already imported and ready to use, so it can reach functionality the generated blocks do not cover without leaving the sandbox the rest of the extension runs in.

What is actually isolated

An extension runs code we did not write and did not review, so it is treated as a genuinely separate trust boundary, not just a separate folder:

• It runs as its own operating-system process, in its own Python environment, confined so it cannot spawn child processes and cannot exceed set memory and CPU limits.
• It receives no BCILattice or BCINexus credential — no login token, no licence key, no route back into the app's own local server.
• Only the library's own public functions are callable — a graph cannot reach an arbitrary Python builtin, because it was never introspected in the first place, not because it is filtered after the fact.
• General internet access is allowed by default (many libraries need it — an atlas download, a model checkout) and can be turned off per extension; a route back to BCINexus itself is refused unconditionally.

Objects never leave the engine

A downstream block that consumes an extension's output does not receive the real object — it receives a small reference token. The extension's own server keeps the actual data and dereferences the token when the next block needs it. Plain numbers and small arrays cross normally; a large array crosses through a temporary file rather than being encoded into a network request. This is what lets two different, even conflicting, versions of the same library run at once without either one touching the other's data.

Free vs Pro vs Enterprise

Downgrading never deletes an environment already on disk — anything already installed keeps working, only a further install is refused.

Sharing a graph that needs one

A pipeline or workflow that uses extension blocks records which extensions it needs, derived automatically from the blocks actually on the canvas. Opening someone else's graph, or importing one from Community, never installs anything on its own — you are shown what it asks for and choose whether to install and start each one yourself.

Publishing a study to BCINexus carries the same list, and it is shown on the study page before download — so a collaborator knows what they will need to install before they commit to downloading anything.

Troubleshooting

See also Using the ML Suite for where extension blocks fit into a pipeline, and Advanced Blocks for the bundled DL Training family they are commonly wired alongside.