Skip to main content

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:

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

You should also add a run dependency on the respective OSX version:

  run:
    - __osx >={{ MACOSX_DEPLOYMENT_TARGET|default("10.9") }}  # [osx and x86_64]

The latter is also set automatically via a run_exports of the compiler('rust') package, but we add this line if you would increase the deployment target later in the feedstock for unrelated reasons.

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.

conda-forge is moving to producing conda artifacts in the version 2 package format (also known as .conda). These artifacts allow for more efficient indexing and maintenance of the ecosystem. Our admin migrations bot will begin making PRs to feedstocks to change them over to the new artifact format. You will need conda version 4.7 or later to use the new .conda artifacts. Please leave a comment on this issue if you encounter problems or have feedback.

The CPython versions 3.8.14, 3.9.14, and 3.10.7 were released some weeks ago to mitigate CVE-2020-10735. The chosen mitigation strategy might cause errors (e.g. ValueError: Exceeds the limit (4300) for integer string conversion) in some libraries. If you are affected, please read the announcement and learn about the available workarounds in the CPython documentation.

The conda-forge team has decided to build and publish these releases with no additional changes. The new packages will be made available on or after 2022-11-10, following Anaconda's decision.