TL;DR: We have made some updates to our Docker images and build time GLIBC selection.

1. We've updated our default docker images to be based on alma9
2. It is now easier to override c_stdlib_version (especially for CUDA-enabled feedstocks), though our baseline of 2.17 hasn't changed.
3. Where necessary, you can more easily switch images by setting os_version: ... (see below).
4. We've consolidated our image names to follow a consistent pattern:

linux-anvil-{x86_64,aarch64,ppc64le}:{cos7,alma8,alma9}

In general, it won't be necessary in the vast majority of cases to override the docker-image, but if you need to do so, you can add the following to conda-forge.yml

os_version:             # just to demo different values;
  linux_64: cos7        # whenever possible, please use
  linux_aarch64: alma8  # homogeneous distro versions
  linux_ppc64le: alma9  # across platforms

We will be slowly migrating conda-forge to use unique feedstock tokens per provider. The feedstock token is used to allow maintainers to copy packages from our staging area to the main conda-forge channel. This change will improve our security posture and help us limit the impact of any leaked tokens. During this migration we will also be using newly implemented feedstock token expiration times to avoid race conditions between token changes and running builds.

The core team has decided to change the time when core meetings happen to accommodate more attendees across different timezones. It will still happen every two Wednesdays, but starting next Wednesday, November 13th 2024, it will alternate between 17:00-18:00 UTC and 14:00-15:00 UTC.

For clarity, these are the next dates:

• November 13th, 2024 at 17:00 UTC
• November 27th, 2024 at 14:00 UTC
• December 11th, 2024 at 17:00 UTC
• December 25th, 2024 at 14:00 UTC
• January 8th, 2025, at 17:00 UTC
• ... and so on.

A new calendar is now available in the Community > Meetings section to help find the dates.

Two weeks ago we called a vote on CFEP-23 to decide whether we move our Element/Matrix chat rooms to Zulip.

This vote has passed and now we are opening the doors to our Zulip instance: https://conda-forge.zulipchat.com/. Please sign up to stay in touch!

As per CFEP-23 (read it for more details), this means that we will stop using our Element chat rooms. Instead all chat activity will continue in Zulip.

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.), you can use the admin-requsts repo to add a glob pattern that matches the pattern of your new outputs. We test these patterns aginst new outputs from the feedstock using the Python fnmatch module. Outputs from the feedstock that match a glob pattern will added automatically. Further details on package output validation can 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.