conda-forge's Linux compilers have always shipped with their own copy of glibc and the Linux kernel headers, known as the sysroot. With conda-forge/linux-sysroot-feedstock#101 you can now tell the conda-forge gcc, g++ and gfortran compilers (and clang) to use the glibc and kernel headers already installed on your Linux distribution:

conda create -n sys-cc \
    -c conda-forge/label/sysroot_dev -c conda-forge \
    gcc gxx gfortran system-linux-sysroot

This post covers why the conda-forge compilers carry a sysroot in the first place, why using the system one makes sense now, and the multi-year work that was needed before this was possible.

conda-forge now has an early, working linux-riscv64 platform. If you have access to a riscv64 machine (or an emulator), you can already try it out:

curl -L -O https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-riscv64.sh
bash Miniforge3-Linux-riscv64.sh
conda install python

That last command actually solves and installs today, giving you a native linux-riscv64 Python built entirely on conda-forge infrastructure.

Following the release of Python 3.15.0rc1, conda-forge has started building Python 3.15 packages. You can create an environment with the Python 3.15 release candidate by running the command:

conda create -n py315 python=3.15 -c conda-forge -c conda-forge/label/python_rc

As with previous feature releases, we start building against the release candidate because the ABI is guaranteed to be stable from here to the final 3.15.0. This is also a release where the python package on Windows looks noticeably different on disk, and where the shared library that every python package used to carry has moved into its own package.

Qt6 has quietly become a first-class citizen in conda-forge. The recent addition of the Qt Designer Python plugin (libpyqt6.so) to the pyqt6 package closed one of the last gaps in the PyQt6 story, but it is a small piece of a much larger, multi-year community effort. This post takes the opportunity to lay out what the whole Qt6 ecosystem now looks like on conda-forge.

The migration spans more than three years. It started with the first attempts at a 6.x build in qt-main-feedstock#44 (2022), gathered urgency once Qt 5.15 reached end-of-life in May 2025, and culminated in the "flip" that made Qt6 the default — the qt6 branch was merged into main in August 2025 (qt-main-feedstock#350). PyQt6 followed in February 2026 (pyqt-feedstock#162), and qt6-webengine landed in May 2026 (qt-webengine-feedstock#90), removing the last major blocker tracked in qt-main-feedstock#349.

In March, we were notified that the colocation where the open-gpu-server CI was running was going to be decommissioned. This meant no GPU CI jobs and no long-running CPU jobs. Fortunately, we could get in touch with several companies that kindly agreed to sponsor the long-running CPU CI. We have not found a replacement for the GPU jobs, but we are still searching!

conda-forge now has partial experimental support for Windows on Arm64 platform. To use the conda-forge packages on an arm64 machine running windows, you first have to install Miniforge for Windows x86_64 since miniforge does not support Windows arm64 yet. Then you can do

set "CONDA_SUBDIR=win-arm64"
conda create -n newenv python
conda activate newenv

This gives you a minimal python environment. You can play around with this untested python binary and provide feedback.

Today marks 100 days since the official release of Python 3.14, and we're thrilled to report that conda-forge has achieved its fastest Python version adoption ever. With 1,932 binary packages available at the 100-day mark, Python 3.14 has surpassed all previous Python releases in early availability.

Earlier this month, Anaconda announced that they are deprecating the r channel bundled in the defaults multichannel. This decision does not impact R packages in conda-forge, which continue to be available without any changes.

On macOS, conda-forge has provided clang, clangxx as the sole compiler for C and C++ sources. We have also provided gfortran to compile FORTRAN sources. Unlike other package managers like homebrew we have not provided gcc nor g++ on macos. The reason to not provide those have been to avoid incompatibility with the clang based toolchain and also the maintenance burden. There are two main incompatibilities. First, clang++ uses libc++ as the standard C++ library and g++ uses libstdc++ as the standard C++ library. Second, clang uses libomp as the OpenMP library whereas gcc uses libgomp as the OpenMP library.

Today, we announce the availability of gcc, g++ compilers on macos. You can install them using:

conda install gcc gxx

Currently we support only gcc 15 and will not support gcc 14 or previous versions.

With yesterday's release of Python 3.14, we not only have Python 3.14 itself available on conda-forge, but also a wide selection of packages to make use of it. As the conda ecosystem is based on binary packages, this means that several packages are already built for Python 3.14.

You can create a new environment by using:

conda create -n py314 python=3.14 -c conda-forge

At the time of writing, the Python 3.14 migration is 77% progressed. This means that:

• 1273 (41%) packages that needed a rebuild were built for Python 3.14
• 1115 (36%) have an open PR to get rebuilt for Python 3.14
• 704 (23%) packages are still waiting for a dependency to be rebuilt.