Skip to main content

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") }}.

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.

Conda-forge is dropping support for CUDA 11.2.

The latest version of the CUDA 11 series is CUDA 11.8. At this point CUDA 11.8+ is well-supported in conda-forge. This is a result of running extensive migration efforts to upgrade conda-forge feedstocks to newer CUDA versions.

CUDA 11.8 packages can be installed and run on the same hardware that CUDA 11.2 supports. Also CUDA 11.8 packages have optimizations for newer hardware that CUDA 11.2 packages do not. So there is a benefit to users to upgrade to CUDA 11.8.

A very small number of feedstocks that appear unmaintained have not been migrated. Issues have been raised on those feedstock to make maintainers aware of this deprecation plan. Until they are updated users can still install the CUDA 11.2 packages they produced previously. These should continue to work. However there will be no way to rebuild these packages without also updating to CUDA 11.8.

To upgrade an older feedstock to CUDA 11.8, simply re-render. If the recipe has a skip or other logic that blocks this from happening, simply remove this logic and re-render to add CUDA 11.8.

The date has been sent to ensure 1 full work week for maintainers to do any remaining updates to move to CUDA 11.8+. In 2024 May, NVIDIA plans to delete the CUDA 11.2 Docker image that conda-forge has been using to build for CUDA 11.2. So it will not be possible for conda-forge to update the CUDA 11.2 Docker image, which will make it much harder to maintain. Feedstock maintainers are encouraged to update before then (if they have not already done so).

With the release of rust 1.75, we now require setting the minimal MACOSX_DEPLOYMENT_TARGET to at least 10.12. You can do this by appending recipe/conda_build_config.yaml with the following content:

c_stdlib_version:       # [osx and x86]
  - '10.12'             # [osx and x86]

and adding {{ stdlib("c") }} as build dependency next to your compiler jinja:

  build:
    - {{ compiler("rust") }}
    - {{ stdlib("c") }}

Note: This entry was update in April 2024 to reflect the new infrastructure for setting MACOSX_DEPLOYMENT_TARGET, see here.

With the Python 3.12 release approaching, we have already started the rebuild of packages for it. Although, there is no offical Python 3.12 release yet, the release candidates of it will have the same ABI. Thus packages built with the release candidate can be safely used with the later offical release. To support rebuilding packages on conda-forge while ensuring Python release candidates don't end up in end-user solves, we have uploaded the Python 3.12.0rc2 and rc3 builds to the conda-forge/label/python_rc channel. The python312 migration adds this channel in the feedstock builds to the Python 3.12 matrix entry. On the offical release of Python 3.12, we will adjust the migration and remove the channel again. Then (on a rerender), feedstock will only consume the main channel again.

Overall, this approach allows us to provide Python 3.12 for a wide range of packages already on the day of the offical Python 3.12 release. At the same time, we have stopped the Python 3.11 migration and added it to the list of default Python versions on conda-forge.

We will bump the minimum MacOS version from 10.9 (released in Oct. 2013, end-of-life since Dec. 2016) to 10.13 (released Sept. 2017, end-of-life since Dec. 2020). The main reason we managed to support 10.9 this long at all, is that conda-forge is able to ship an up-to-date C++ standard library for OSX, libcxx, superseding the old one present in the MacOS SDK on the system (at least from the point-of-view of the respective conda environments).

However, several core packages in the ecosystem now require at least 10.13 (or will very soon), in a way that we cannot be circumvent. These packages include libcxx, starting with version 17.0. This change will not affect already published artifacts, but in the near future, all new builds for OSX will require at least 10.13. This constraint will be implemented through the __osx virtual package, but the details of how we will achieve this are still being worked out. Only conda versions 4.8.0 or newer have this virtual package. If you are using a system with MacOS older than 10.13 and are using conda older than 4.8.0, you will need to either upgrade conda to at least 4.8.0 or upgrade your system to at least MacOS 10.13.

As you may be aware, we have delayed the deprecation of our CentOS 6 build system the linux64 platform several times. We have now set a formal deprecation date to be June 30, 2024. This date matches the end of extended life-cycle support from RedHat for RHEL 6. After this date, we build packages against CentOS 7 by default for linux64.