# staged-recipes is where a conda-forge package is still a pull request

> The conda-forge staged-recipes repository is a holding area where a recipe lives only as a pull request, and merging it is what causes a feedstock repository and a build to be created. It suits maintainers who want to package a Python or R project for conda-forge without setting up a feedstock themselves.

**conda-forge/staged-recipes** — A place to submit conda recipes before they become fully fledged conda-forge feedstocks

- Repository: https://github.com/conda-forge/staged-recipes
- Website: https://conda-forge.org
- Stars: 849 · Forks: 6,447
- Language: Python
- License: BSD-3-Clause
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/conda-forge-staged-recipes

## A holding area for recipes that are not feedstocks yet

The repository does one thing and does it before a feedstock exists. The README calls it a holding area for recipes destined for a conda-forge feedstock repo, and the description says it is a place to submit conda recipes before they become fully fledged conda-forge feedstocks. That is the whole concept, and it exists because a feedstock is a per-package repository with its own build configuration, and creating one by hand is work you should not have to do for a first contribution. The repository layout supports the same idea. There is a `recipes/` directory where each package gets a folder, a `build-locally.py` script, a `pixi.toml` for the local workflows, a `conda-forge.yml` file, an `environment.yaml`, a `broken-recipes/` directory, and CI configuration in `.azure-pipelines/` and `.ci_support/`.

## Fork, branch, folder, recipe.yaml

The getting started steps are short enough to state exactly. You fork the repository, make a new branch from `main` for your package's recipe, and make a new folder in `recipes` for the package, starting a v1 `recipe.yaml`. The format policy is stated firmly: new recipes should use the v1 format, and the v0 `meta.yaml` format is deprecated for new recipes and should only be used in exceptional circumstances where v1 cannot support the recipe, in which case you explain the exception in the pull request. Two example recipes ship in the tree, `recipes/example-v1` and `recipes/example-v0-deprecated`, the latter retained only for those exceptional cases. The README also links the maintainer documentation for adding packages and a search for existing examples.

## What happens after the pull request is merged

The payoff is that merging is what creates everything else. The README lists it directly: a new feedstock repository is created in the GitHub conda-forge organization, a build of your package is triggered, and the package is uploaded to conda-forge. If it is your first recipe you also receive an email about accepting an invitation to a new GitHub group. Before that, the pull request is built on Linux, macOS and Windows, and you ask for review by mentioning the appropriate review team or using the bot command in a pull request comment. The build of your package being tested on all three platforms before merge is the reason a local build is recommended as step four rather than an optional extra.

## The merge queue and the create feedstocks job

Conversion happens in two steps, and the first one will surprise you if you skip it. Pull requests are put into a merge queue for testing against the latest CI scripts, and the README warns that your pull request may fail in the merge queue, in which case it needs to be remerged, with the advice to update the branch with the latest commits from `main` on the upstream repository first. Once recipes are merged into `main`, they are turned into feedstocks by the create feedstocks CI job, which runs on the `conda-forge/admin-requests` repository. That job's failures are often caused by API rate limits from the services conda-forge uses, which can leave empty feedstock repositories, and the README says this resolves itself automatically, with support on Zulip if it persists.

## Building locally with build-locally.py

The local path exists to save community resources as much as to help you. The README says that while everything eventually has to work in CI for a recipe to be merged, building locally is a good way to learn more about conda-forge and make better use of donated community resources. The `build-locally.py` script guides you through the process, then launches the platform-specific scripts, and the resulting artifacts end up under `build_artifacts` in the repository directory. On Linux everything runs in a Docker container with the `staged-recipes` directory mounted as a volume. On macOS and Windows two environment variables control where files are kept: `MINIFORGE_HOME`, where the build tools are installed, which defaults to `~/Miniforge3`, and `CONDA_BLD_PATH`, where the build artifacts are kept, which defaults to `~/Miniforge3/conda-bld` on macOS and `C:\bld` on Windows.

## pixi tasks for the three platforms

The same work is exposed as pixi tasks, and the README describes pixi as a workspace-based environment and task runner optimized for conda packaging. The local workflows and their dependencies are captured in `pixi.toml`, and pixi itself is installed through the conda package manager:

```bash
$CONDA_EXE install -c conda-forge pixi
```

The per platform tasks are named by operating system:

```bash
pixi run build-linux
pixi run build-osx
pixi run build-win
```

On Linux the task launches a Docker container, provisions the tools and builds the recipe. On macOS it finds or provisions the conda executable, provisions a conda environment with the necessary tools, which involves fetching and caching the necessary Apple SDKs, and then builds. On Windows it does the equivalent without the Docker step. These tasks pass any extra arguments through to `build-locally.py`, including `--help`, and the artifacts again land under `build_artifacts`. You can list what is available with `pixi task list`.

## CONDA_EXE, micromamba and miniforge

The build needs a conda-compatible package manager, and the README handles that case explicitly. `$CONDA_EXE` is described as the well-known environment variable used for a conda package manager in an activated POSIX shell session, and on Windows the same variable is written as `%CONDA_EXE%`. If you have never used conda-forge before, you may need `conda`, `mamba` or `micromamba`. If no compatible `$CONDA_EXE` is found, `build-locally.py` may download micromamba, which as a single file static binary is not installed per se and can be used to create other environments. For a more traditional installation, downloading, installing and activating a miniforge installer gives you `conda` and `mamba` with conda-forge as the default package source, and if miniforge is found, `build-locally.py` uses it instead of downloading micromamba.

## grayskull, conda-smithy, and who reviews your recipe

Two tools do the heavy lifting around the recipe itself, and both are named in the README's own table of contents. grayskull can generate recipes from Python packages on PyPI, and the sentence about R packages is cut off in the version of the documentation available here. The linting step is done with conda-smithy, which is also where the README points for a fuller explanation of what conda-forge is. Review is not anonymous: the README tells you to ask for review or help by mentioning the appropriate review teams, or by using the bot command in a pull request comment, and it links a Zulip chat for questions. The licence is BSD-3-Clause, there are no GitHub releases, and the last push was on 2026-10-22, so the repository is where the current process lives rather than a versioned artifact.

## Conclusion

Adopt the staged-recipes workflow when you are adding a package to conda-forge for the first time, because it removes the need to create and maintain a feedstock repository by hand, and the merge queue gives you a real test against current CI scripts. Do not adopt it as a place to keep a package you already maintain, since a merged recipe leaves this repository and becomes a feedstock. Verify first that you can run the build locally with `build-locally.py` before requesting review, and write your recipe in the v1 `recipe.yaml` format unless v1 genuinely cannot express it.

## FAQ

### What is the conda-forge staged-recipes repository for?

It is a holding area for recipes that are not yet feedstocks. You submit a recipe as a pull request, and when it is merged a new feedstock repository is created, a build is triggered and the package is uploaded to conda-forge.

### Should a new conda-forge recipe use recipe.yaml or meta.yaml?

New recipes should use the v1 `recipe.yaml` format. The v0 `meta.yaml` format is deprecated for new recipes and should only be used in exceptional circumstances where v1 cannot support the recipe, and the exception has to be explained in the pull request.

### How do I build a recipe locally before opening a pull request?

Use `build-locally.py`, which launches the platform-specific scripts and leaves the resulting artifacts under `build_artifacts` in the repository directory. On Linux it runs everything in a Docker container, and pixi tasks named `build-linux`, `build-osx` and `build-win` wrap the same work.

### Why did my pull request fail in the merge queue?

Pull requests are queued for testing against the latest CI scripts, and a failure means the branch needs to be updated with the latest commits from `main` on the upstream repository and remerged.

### What do MINIFORGE_HOME and CONDA_BLD_PATH control?

They control where local build files are kept on macOS and Windows. `MINIFORGE_HOME` is where the build tools are installed, defaulting to `~/Miniforge3`, and `CONDA_BLD_PATH` is where build artifacts are kept, defaulting to `~/Miniforge3/conda-bld` on macOS and `C:\bld` on Windows.

## Sources

- [conda-forge/staged-recipes on GitHub](https://github.com/conda-forge/staged-recipes)
- [Issues](https://github.com/conda-forge/staged-recipes/issues)
- [License: BSD-3-Clause](https://github.com/conda-forge/staged-recipes/blob/main/LICENSE)
- [Project website](https://conda-forge.org)
- [README](https://github.com/conda-forge/staged-recipes/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/conda-forge-staged-recipes