Advanced
The following how-to guides are available in this category:
Deal with numpy
Finding numpy.get_include() in setup.py, numpy in build-system.requires of pyproject.toml, dependency('numpy') in meson.build, or cimport statements in .pyx or .pyd files are a telltale sign that the package links against NumPy.
Enable additional architectures
By default, feedstocks are created with support for the main platforms (e.g. linux-64, osx-64, win-64). Additional ones may be available in an opt-in fashion. The configuration can be changed manually in conda-forge.yml, or through automated migrations.
Talk to the bots
Some parts of the conda-forge automation are exposed as "bot commands" that can be invoked from issue titles and comments. You can check the full list in the admin-web-services documentation.
Cross-compile
Cross-compiling means building a package for a different architecture or a different operating
Move from autotools to CMake
Some packages maintain both an Autotools build and a CMake build. Some maintainers
Building packages for Windows
3 items
Enable CUDA
Create multi-output recipes
Maintain several versions
The conda-forge workflow assumes that a push to any branch in the feedstock repository will result in a build being uploaded to the conda-forge channel (and that's why PRs must always be opened from a fork!).
Self-hosted runners
conda-forge has access to external CI resources that can provide GPU-equipped and/or long-running builds (beyond the usual 6h limit).
Package a fork
Sometimes you face the possibility of needing to package a fork.