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.
The main difference between these packages and a vanilla gcc installation
or the installation from Homebew is that they use libomp as the default
OpenMP library and libc++ as the default standard C++ library.
This difference makes binaries compiled with gcc, g++ compatible with
binaries compiled with clang, clang++.
Another interesting consequence of the infrastructure work done to enable
this is that this enables cross compilation of C/C++ sources using gcc,
g++ to cross-compile macOS binaries from Linux (previously only clang
supported this) and also cross-compile windows binaries from macOS using
the GCC/MinGW compilers.
To use them in conda-build recipes, you can use
requirements:
build:
- {{ compiler('gcc') }} # [osx]
- {{ compiler('gxx') }} # [osx]
- {{ stdlib('c') }}
You can also do
c_compiler: # [osx]
- gcc # [osx]
c_compiler_version: # [osx]
- 15 # [osx]
cxx_compiler: # [osx]
- gxx # [osx]
cxx_compiler_version: # [osx]
- 15 # [osx]
in conda_build_config.yaml and continue to use the well-established
{{ compiler("c") }} and {{ compiler("cxx") }} macros in the recipe;
be aware that you're then responsible for updating the version roughly once
per year (to keep pace with the rest of conda-forge).
When you are using gcc locally, similar to clang, we make some guesses
about where the macOS SDK is located. This might fail sometimes and setting
the environment variable SDKROOT to the root of the macOS SDK should make
gcc look in that folder.
We also add by default -L $CONDA_PREFIX/lib -Wl,-rpath,$CONDA_PREFIX/lib
when linkingfor local builds with the conda-gcc-specs package that is
installed by deault with gcc package. If you want to avoid that you can
install the gcc-no-conda-specs package alongside gcc.
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:
During the first half of the year, conda-forge has been subject to a security audit in partnership with Open Source Technology Improvement Fund (OSTIF), Sovereign Tech Agency (STA) and the security firm 7ASecurity. This effort has resulted in the identification and remediation of 13 findings with security impact, a custom threat model, and a supply chain security analysis. Full details are now publicly available in the final report.
Today, 2025-04-11, marks the 10th anniversary of the conda-forge community.
Join us in this Zulip thread and share how you got involved with conda-forge, how this community has helped you, or just to show appreciation to the thousands of volunteers that make this effort possible!
To many more years! 🎉
In the past few months, conda-forge has been engaging with an external security audit in collaboration with
the Open Source Technology Improvement Fund (OSTIF). The full results of this audit will be
made public once it is complete per OSTIF responsible disclosure policies.
During this process, OSTIF and their contractor uncovered misconfigured infrastructure which exposed the anaconda.org
token for the conda-forge channel to all feedstock maintainers. The token was exposed from on or about 2025-02-10 through
2025-04-01. See our GitHub Security Advisory
for more details.
The conda-forge team is excited to announce that the v1 recipe format is available on conda-forge. The v1 recipe format is a community initiative dating back over 3 years to improve the recipe format for conda packages. If you are a maintainer of a feedstock on conda-forge, you have probably dealt with meta.yaml files that conda-build utilizes. The file format has some limitations which is why the community has come together to come up with an improved version of the format: the v1 format.
We introduce noarch variants for python packages on conda-forge that have compiled extensions but with pure python reference implementations to make life easier for early adopters of new python variants.
conda-forge now supports Python 3.13 on conda. You can create a new environment with Python 3.13 by running the command:
conda create -n py313 python=3.13 -c conda-forge
On March 29th, 2024, at 18:07 UTC, the core team learnt about the recently disclosed xz backdoor, now labeled as CVE-2024-3094.
To the best of our knowledge, conda-forge's artifacts for xz are not affected.