conda-forge/feedstocks: the index repository behind every conda-forge package

What conda-forge/feedstocks actually is

The README opens with a sentence that settles most confusion: this repository "does not get updated by hand, rather it is an automated summary of all the individual package feedstocks which have their own separate repositories." That single line defines the whole project. There is no build system here, no recipe to edit, no CI configuration that produces packages. The repository is a map. The top level holds four entries: .gitmodules, LICENSE, README.md and a feedstocks/ directory. The .gitmodules file is the tell. The individual feedstocks are registered as submodules, so the feedstocks/ directory is not a copy of every recipe but a set of pointers into the repositories that do hold them.

The audience is narrow and specific. A person who wants to report a bug in a conda-forge package, or send a patch to its recipe, needs to know which repository owns that package. Searching GitHub for the package name often returns forks, mirrors and unrelated projects. This repository answers that question directly, and the README gives a worked example: for the package unzip, the issue tracker is https://github.com/conda-forge/unzip-feedstock/issues. If you are not trying to locate the owning repository, this project probably has nothing for you.

How the submodule layout routes you to the right repository

The mechanism is git submodules plus automation. Each conda-forge package has its own feedstock repository, and this repository records a reference to each of them under feedstocks/. Because the README states the summary is generated automatically, the practical consequence is that a pull request against this repository is not the way to change anything about a package. Edits belong in the feedstock that owns the recipe.

The README also draws a boundary between three different kinds of request, and the boundary is worth reading carefully because it is the part people get wrong:

- An issue with an individual package goes to that package's feedstock, for example https://github.com/conda-forge/unzip-feedstock/issues. - A request for a new package goes to https://github.com/conda-forge/staged-recipes/issues. - A wider issue, one that is not about a single package, goes to https://github.com/conda-forge/conda-forge.github.io/issues.

Notice what is absent. There is no instruction anywhere in the README to open an issue in this repository, and no description of what a change to the feedstocks/ directory would even mean. That silence is consistent with the automated-summary claim, but it also means the README documents routing and nothing else. It says nothing about how often the summary is refreshed, what happens when a feedstock is retired, or whether removing a submodule entry is supported. Treat the routing table as the documented contract and everything else as unstated.

How to find a package's feedstock repository

There is no installer. The README gives no install command, no package name and no setup step, because the project is a git repository rather than software you install. It also gives no clone instructions, so the documented route is the naming convention rather than a checkout. The README's own example shows the pattern: for the package unzip, the issue tracker is https://github.com/conda-forge/unzip-feedstock/issues. Take the package name, append -feedstock, and you have the repository.

For the common task, which is simply finding the issue tracker for one package, that convention is the whole procedure. If you would rather confirm from the repository itself, the feedstocks/ directory is the consolidated list to check, and the top-level .gitmodules file is where the submodule references are registered. The README does not document how to clone or initialise those submodules, so any local checkout procedure is outside what the project states. A full local copy of every feedstock is also large, which is another reason the naming convention is the faster route when you only need one package.

Where this repository is the wrong destination

The most common failure mode is filing in the wrong place. A user hits a broken package, searches GitHub, lands on conda-forge/feedstocks because it appears to be the central conda-forge repository, and opens an issue there. According to the README, that issue is in the wrong tracker. The correct destination is the package's own feedstock, and the README's unzip example is the template for finding it.

The second failure mode is expecting a new package to appear here. It will not, and the README says where to go instead: https://github.com/conda-forge/staged-recipes/issues. A new package is proposed through staged-recipes, and only after it is accepted does it get its own feedstock repository, at which point the automated summary can point at it.

The third is a matter of scope. This repository is a summary of package feedstocks. A problem that spans many packages, or concerns conda-forge infrastructure rather than one recipe, is not a per-package issue and the README routes it to conda-forge/conda-forge.github.io. If your task is building, testing or publishing a package, this repository has no role at all; it never contains the recipe you would edit.

The alternative: going straight to the package's own feedstock

The direct alternative is to skip this repository entirely and work in the feedstock that owns the package. The difference in approach is not cosmetic. This repository is an index of pointers; the feedstock is the working repository that holds the recipe and the build configuration, and it is where issues and pull requests are actually handled. For anything that changes a package, the feedstock is the only one of the two that can accept the change.

There is a second, smaller alternative for the same lookup task: GitHub's own search and the naming convention. Because feedstocks follow the pattern <package>-feedstock under the conda-forge organisation, typing that name into a browser or a search box often reaches the repository without any clone. The index repository is the authoritative summary of which feedstocks exist, but for a single known package the convention usually gets you there first.

What the index buys you is breadth. If you need to survey what exists, or resolve a package name whose repository you cannot guess, the feedstocks/ directory is the consolidated list. If you already know the package name, the convention is cheaper, and the index repository adds nothing you cannot derive from it.

Maintenance cost, licence and what the README leaves open

The licence is BSD-3-Clause, stated at the top level of the repository. That is a permissive licence, and the repository's own LICENSE file is the authority on its terms. The practical licence question here is not about this repository at all: the recipes and build scripts live in the individual feedstock repositories, and each of those carries its own licensing. Cloning the index does not grant you anything over the packages it points to. Nothing in the README addresses licensing beyond the top-level file, so treat any assumption about the submodules as unverified.

Maintenance cost is close to zero for a consumer, because the README states the summary is automated and not edited by hand. You do not maintain an installation, and there is no service to run. The cost you do carry is the size of a local copy of every feedstock if you want them all, which is why the naming convention is the better route for a single lookup.

What the README does not document is as important as what it does. There is no refresh schedule, so how current the feedstocks/ directory is at any moment is not stated. There is no description of how a feedstock is added to or removed from the summary. There is no rollback or recovery procedure, and no versioning scheme, because this is not released software. The repository is not archived, so it has not been frozen, but the README offers no commitment about how the automation behaves. If your work depends on the index being complete at a particular moment, that is the gap to check before you rely on it.

Editorial conclusion

Use conda-forge/feedstocks when you need to find which repository owns a package before filing an issue or opening a pull request. Do not use it to request a new package, which the README routes to conda-forge/staged-recipes, and do not use it for organisation-wide problems, which go to conda-forge/conda-forge.github.io. Before relying on it, open the feedstocks/ directory on the main branch and confirm that the package you care about has an entry there, because the README does not describe a completeness guarantee, a refresh schedule or any rollback procedure.

Frequently asked questions

Official sources

1. Official README
2. Project repository