Share a recipe¶

Recipes live in three places, with three levels of guarantee. This is the usual layout of scientific Python ecosystems (a small core, curated affiliated packages, and everyone's own code), applied to measurement recipes.

Tier	Where	What	Who validates	How you get it
Bundled	the kernel, `spectro_kernel/presets/catalog/`	a dozen generic recipes that show the bricks (`snr_check`, `balmer_quick`, the reduction template)	the kernel maintainers, in the kernel CI	`pip install spectro-kernel`
Curated collection	github.com/matthieulel/spectro-kernel-recipes, published on PyPI	campaign and domain recipes: Be stars, novae, binaries, solar, reduction by instrument type	review by pull request, CI validation, strict criteria	`pip install spectro-kernel-recipes`
Yours	your repository, your application, a folder on your disk	everything else	nobody	`SPECTRO_PRESET_PATH`, or your own package

Installing the curated collection¶

pip install spectro-kernel-recipes
spectro presets                 # the collection's recipes appear with source package:spectro-kernel-recipes
spectro preset show be_halpha_ew

The collection declares an entry point in the spectro_kernel.presets group; after installation the kernel discovers its recipes exactly like the bundled ones. No network access at run time: the recipes are files in the installed package.

Using your own recipes¶

Put your YAML files in a folder and point the kernel at it:

export SPECTRO_PRESET_PATH=$HOME/spectro-recipes
spectro presets                  # your recipes are listed with their folder as source

Or run a file directly, without registering anything:

spectro pipeline ./my_recipe.yaml --input obs.fits --profile my_setup.yaml

An application built on the kernel can ship its recipes as a package too: declare the entry point in its pyproject.toml, pointing at a Path that holds the YAML files.

[project.entry-points."spectro_kernel.presets"]
my_app = "my_app.recipes:RECIPES_DIR"

Contributing to the curated collection¶

The collection follows the same rules as the bricks, transposed:

One recipe, one file, one measurement, named <domain>_<measurement> (be_halpha_ew, nova_balmer_decrement, binary_rv_ccf). The name says what is measured, not who wrote it nor with which instrument.
No instrument value in a recipe. Anything that depends on the spectrograph, the site or the observer is a variable with a description.
No convention without a source. The references list names the papers the method rests on; the conventions text states plainly the choices the literature leaves open (which continuum band, which window), so a reviewer can discuss them.
status tells the reader what to expect. A recipe enters as draft, becomes reviewed when its conventions are documented and discussed, and reference when the community adopts it as the way to make that measurement. Only reference recipes are presented as such in the catalogue; the others are listed with their status.
The CI validates every file with spectro preset validate against the latest kernel, so a recipe that stops matching the bricks (after a major version change of one of them) is caught before it is published.

To contribute: fork the collection, copy TEMPLATE.yaml, fill it in, run spectro preset validate locally, open a pull request. The review discusses the conventions, not the YAML syntax.

What does not belong anywhere here¶

A hosted registry where anyone uploads recipes without review. The kernel manages no accounts, runs no upload service, and executes nothing that was not installed or written on the machine it runs on. The "store" is the curated collection, the "download" is pip install, and the "catalogue" is this documentation, generated from the recipes' metadata.