We have changed our feedstock output validation procedure. Instead of automatically adding new packages to existing feedstocks (e.g., when a new output is added), we will now require that maintainers submit a PR to add the new output via our admin-requests repository. New feedstocks created via staged-recipes will have their outputs added automatically. If you maintain a feedstock that regularly adds new outputs (e.g., llvmdev has libllvm18, libllvm19, etc.), we have created a list of feedstocks with allowed glob patterns. These feedstocks will have any outputs matching their glob patterns added automatically. If you would like to add your feedstock to this list, please submit a PR. Further details on package output validation cna be found in our documentation.

For nearly two years now, we have favored the use python-build as the package name for the PyPA build project over build. In fact, the build feedstock on conda-forge is archived and has not had its version updated. To complete this transition, we are going to mark all existing build packages as broken, provide a more detailed linter hint, and turn off the migration infrastructure we've been using to help move feedstocks. Any questions or comments can be directed to the GitHub issue on this work.

Starting with Python 3.13, pip will no longer have setuptools and wheel as dependencies by default. While this default made sense at the time conda-forge was started (over 8 years ago!), with the advent of Python packaging build backends (e.g., flit, poetry, hatchling, etc.), this default is no longer correct. Instead, you will need to specify wheel and/or setuptools explicitly in the host section of your recipe if you need them. At first, pip for versions of Python before 3.13 will be unaffected. However, after the completion of the Python 3.13 migration, we will remove these dependencies from pip for all versions of Python. Follow GitHub issue #2252 for more information and updates.

TL;DR: We are planning to remove PyPy from conda-forge feedstock recipes in a few weeks (and thus to stop building new releases of packages for PyPy), unless there is substantial enough interest to justify the continued maintenance effort.

With the Miniforge 23.3.1 release, the Miniforge and Mambaforge installers became essentially identical. The only difference between the two was their name and, subsequently, the default installation directory.

Maintaining both installers adds unnecessary burden to our support infrastructure and creates confusion among end users. As a result, last year we decided to discourage the usage of Mambaforge in favor of Miniforge.

A year later, we would like to formally sunset Mambaforge. All users are encouraged to switch to Miniforge. Remember they contain the same packages, so the only difference is the default installation directory.

The deprecation process will roughly follow this calendar:

• August 2024: The Mambaforge installers will warn about the deprecation and make the user wait 30 seconds before continuing.
• October 2024: The Mambaforge installers will refuse to install during several pre-specified date ranges (i.e., "brownouts") in order to encourage users to switch to Miniforge. These dates are
  • Every two weeks in October 2024 (2024-10-01, 2024-10-15)
  • Every ten days in November 2024 (2024-11-01, 2024-11-10, 2024-11-20, 2024-11-30)
  • Every five days in December 2024 (2024-12-05, 2024-12-10, 2024-12-15, 2024-12-20, 2024-12-25, 2024-12-30, 2024-12-31)
• January 2025: The Mambaforge installers will stop being built and distributed.

In preparation for the NumPy 2 release, we have begun a migration of all conda-forge packages that depend on numpy during the build (so in requirements/host). The migration status is tracked on our status page. Particular package's status can be found there. Specific recommendations for maintainers updating packages can be found in the migration PRs themselves. Please reach out through the usual channels if you have any questions.

Azure Pipelines has deprecated the macos-11 images. As a result we have bumped the default Azure vmImage setting to macos-12. You can check this issue for more details.

Our compiler stack per platform generally uses the "default" compiler for that platform, see e.g. here.

In practice, this meant that

c_compiler:
  - gcc         # [linux]
  - clang       # [osx]
  - vs2019      # [win]
cxx_compiler:
  - gxx         # [linux]
  - clangxx     # [osx]
  - vs2019      # [win]

was the only possible choice for C/C++ compilers.

Recently, we finished adding preliminary support clang / clangxx as C/C++ compilers also on linux and windows, starting from clang 18. This is still very fresh, so bugs are possible, and we ask not to change the default compilers on feedstocks unless there are compelling reasons.

In any case, it is now possible to use the following configuration in recipe/conda_build_config.yaml (note the lack of platform selectors):

c_compiler:
  - clang
c_compiler_version:
  - 18
cxx_compiler:
  - clangxx
cxx_compiler_version:
  - 18

As you might have noticed, for the last few months we have been changing different parts of the conda-forge.org website. Read more to learn more about what we changed, how it works and how to contribute.

Almost since the inception of conda-forge, the baseline version of our standard library ("stdlib") for C has not changed. This library comes with extra complications because it is an essential part of the operating system, and one of the few things that conda/mamba/etc. cannot ship safely.

As the ecosystem has moved on and many packages are starting to require newer baseline versions, we need to follow suit at some point. However, to avoid breaking users on older systems, we need to have infrastructure in place that allows our packages to have sufficiently accurate metadata, such that conda can avoid the installation of a package requiring a newer stdlib on an old system.

After many discussions across conda-forge stakeholders, the solution we arrived at is the introduction of a new Jinja2-function {{ stdlib("c") }}, which reflects that a given recipe requires a C stdlib. Making this relationship explicit will make it easy to correctly reflect the requirement for newer stdlib versions per feedstock, as well as in our global pinning.

Up until now, the stdlib was handled implicitly as part of the compiler stack. In order to allow this transition to happen, we need to introduce this function to essentially all compiled recipes. This will be done in stages, first for a single migration, and then attached to all ongoing migrations in conda-forge.

The logic of the piggyback migrator tries to correctly handle most scenarios, but it is impossible to cover all corner cases. As for some general rules that all feedstock maintainers are free to apply independently:

• if a feedstock uses a - {{ compiler(...) }} jinja in the build section, add a line with - {{ stdlib("c") }} to the build environment.
• if a feedstock uses - sysroot_linux-64 2.17 # [linux64] (or a variation), remove this line and add the following to your conda_build_config.yaml:

  c_stdlib_version:              # [linux]
    - 2.17                       # [linux]
  
• if a feedstock sets MACOSX_DEPLOYMENT_TARGET in conda_build_config.yaml, for example to 10.13 for x86_64, replace that section with the following (note, this does not apply to MACOSX_SDK_VERSION!):

  c_stdlib_version:              # [osx and x86_64]
    - 10.13                      # [osx and x86_64]
  
• In meta.yaml, you can then remove any variations of - __glibc >=2.17 or - __osx >={{ MACOSX_DEPLOYMENT_TARGET }} # [osx and x86_64], as this will henceforth be handled through - {{ stdlib("c") }}.

Following the application of any of the above changes, the feedstock should be rerendered.

As these mechanisms begin rolling out, we will also update the maintainer documentation in the conda-forge knowledge base. For more details, see this issue.