Package managers and Docker

For people who would rather not click an installer, and for pipelines that run without anyone watching.

Homebrew planned

macOS, once the notarised build exists. A cask cannot ship an unsigned application without users hitting Gatekeeper on every update.

coming

brew install --cask signal-studio

winget planned

Windows. The manifest is written; submitting it to the community repository waits on code signing, which winget checks.

coming

winget install NeuraCrypt.SignalStudio

Chocolatey planned

Windows, for machines managed centrally. Same blocker as winget.

coming

choco install signal-studio

Linux planned

The application compiles on Linux today. Packaging and testing it across distributions is what has not been done, not the build itself.

Tracked as R-010 on the roadmap. A request from someone who would actually use it moves it up.

Why these are all waiting on the same thing

Homebrew casks, winget and Chocolatey all expect a signed binary, and they are right to. Until the installers are code-signed, submitting them would hand users a warning dialog on every install and every update, which is worse than not being there at all. Code signing is R-003.

Docker

For running pipelines with no interface: on a cluster, in a CI job, or over many subjects at once. The image carries the Python engine and the card library, without the desktop application.

terminal

planned

# Run one pipeline over one recording
docker run --rm \
  -v /path/to/data:/data \
  -v /path/to/pipelines:/pipelines \
  ghcr.io/neuracrypt/signalstudio:0.9.0 \
  run /pipelines/ccep_soz.sbuilder --input /data/sub-01 --output /data/derivatives

# Over every subject in a BIDS dataset
docker run --rm -v /path/to/bids:/data \
  ghcr.io/neuracrypt/signalstudio:0.9.0 \
  batch /pipelines/preprocess.sbuilder --bids /data --participants all

Why an image rather than a pip package

Because the thing that breaks a reproduction three years later is not the analysis code, it is the versions underneath it. An image pins the interpreter, the reference libraries and the card versions together. Citing signalstudio:0.9.0 in a methods section names all of it at once.

What it will not do

No interface, no canvas, no visualiser. It executes a pipeline file you built in the desktop application. If you want to see what a step does, do that on your own machine first and take the file to the cluster afterwards.

The Dockerfile is in the repository at docker/Dockerfile. The published image waits on the Linux build, since both need the same headless engine packaging.

Verifying any of these

Whichever route you take, the SHA-256 of the installer is published on the download page and in the archive. A package manager that fetches from the same GitHub release will produce the same hash; if it does not, something is wrong and you should stop.