Add a new recipe¶
-
Pick a sibling recipe with a similar shape (CMake project? Header-only? Python package?) and copy its directory:
-
Edit
recipes/<new-pkg>/recipe.yaml: context.version— current upstream release.source.url— tarball URL (GitHubarchive/refs/tags/, GitLab CERNarchive, etc.). Use the same template variables as the surrounding recipes so Renovate can update it automatically.source.sha256—curl -fsSL <url> | sha256sum.requirements.{build,host,run}— declare every sibling recipe this package depends on by name. rattler-build resolves the build order from these lists, so this is the only place to express ordering.tests:— at minimum apackage_contents:block listing the headers / libs / CMake configs the build is expected to produce. For runtime-executable packages add ascript:test that runs a Python import orroot -l -qinvocation.about:— populatehomepage,repository,summary,description,license(SPDX),license_file.-
extra.recipe-maintainers:— your GitHub handle, plus at least one co-maintainer where possible. -
Adjust
recipes/<new-pkg>/build.shfor the build system in use. -
From the repo root, dry-run the build locally:
-
Open a PR. CI runs
pixi run build-all(rattler-build build --recipe-dir recipes/ --skip-existing=all), which rebuilds every recipe whose dependencies changed. Uploads toprefix.dev/shipare gated on push tomain. -
After merge, decide whether the recipe is an upstream candidate and update the table.
Notes¶
- Recipe directory name must equal the
package.nameinrecipe.yaml. rattler-build's cross-recipe dependency resolution keys off the name inrequirements:. - Don't add the recipe to a separate manifest file — there isn't
one. The
requirements:block is the single source of truth for dependency order. -
For a single-recipe local iteration, run the inline form:
or, for the recipe currently most under churn, the build-<name>
pixi task shortcut.