Album Ecosystem
Album is more than a command line tool. The core framework is an extensible substrate: plugins implement different deployment targets (Docker images, standalone installers, batch / distributed execution, GUI, LLM-agent orchestration) on top of the same solution and catalog primitives. You write the solution once; the ecosystem decides how it reaches its consumers.
In paper terms, Album acts as an executable digital library that composes with — rather than replaces — package managers, workflow engines, and container runtimes. See case-studies for end-to-end examples that mix several plugins.
Graphical User Interface
Install the GUI plugin to browse catalogs, install and run solutions visually:
micromamba install album-gui -c conda-forge
Or via pip:
pip install album-gui
Launch it:
album gui
You can also create desktop shortcuts for individual solutions:
album add-shortcut group:name:version
Plugins
All plugins are installed via micromamba (recommended) or pip into your Album environment
and add new commands to the album CLI automatically.
Plugin |
Install |
Command |
What it does |
|---|---|---|---|
|
|
Graphical frontend for browsing and running solutions |
|
|
|
Package any solution into a Docker container |
|
|
|
Batch-run solutions over multiple inputs |
|
|
|
Create standalone executables for solution distribution |
See the individual pages for details: Docker · Distributed · Package
Workflow integration
Because each Album solution is a self-contained executable step, solutions can
be reused as steps inside an external workflow engine (Snakemake, Nextflow,
Galaxy, …) without rewriting the routine. The same solution that you run
interactively on a laptop can be invoked from a workflow rule on an HPC
cluster. See case-studies (scenario C) for a concrete example
combining Album with Snakemake and album-docker.
Finalize & Distribute
When a solution is mature, three complementary paths take it from “running on my machine” to “long-term distributable artifact”:
Three finalization paths: containerize with album-docker (A), build a
standalone installer with album-package (B), or pin dependencies with
conda-lock and publish to a public catalog (C) (from
arXiv:2110.00601, Fig. 5).
Pick the level of stabilization appropriate for your collaborators and reuse scenario:
album-docker— best for long-term portability, HPC, and workflow-engine integration.album-package— best for sharing with less-technical collaborators on a specific OS (one double-clickable installer that bundles Album, micromamba, and your solution).Public catalog + pinned environment — best for community discoverability and citation, especially combined with Zenodo DOIs.
Catalog Websites
Catalogs can have a Gatsby-powered website that shows all available solutions. When creating
a catalog, use the -gatsby template variants:
album clone template:catalog-gatsby [repo-url] [catalog-name]
album clone template:catalog-request-gatsby [repo-url] [catalog-name]
The website is built and deployed automatically via GitLab Pages or GitHub Pages CI.
Zenodo DOI Minting
Request catalogs can optionally mint DOIs for every deployed solution via Zenodo. See Zenodo catalog setup for a step-by-step guide.
Python API
Album can be used programmatically from Python — useful for scripting workflows or building integrations. See Python API.
MCP Integration
Album solutions are tool-grounded building blocks that LLM agents can discover, install, and chain via the Model Context Protocol. Because the agent can only call solutions that exist in your catalogs, Album acts as an explicit inventory of executable artifacts — a practical mechanism for constraining the free-form shell commands that LLMs would otherwise hallucinate.
LLMs interact with Album in two complementary ways:
Drafting — generating new
solution.pyfiles (see Drafting solutions with LLMs in the solution-dev guide).Orchestrating — searching, installing, and chaining existing solutions to fulfil a user request.
See Album MCP for setup, the available tools, and a typical agent workflow.