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:
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.
Azure Pipelines has deprecated the macos-11 images. As a result we have bumped the default Azure vmImage setting to macos-12.
You can check this issue for more details.
Our compiler stack per platform generally uses the "default" compiler for that platform, see e.g. here.
In practice, this meant that
c_compiler:
- gcc # [linux]
- clang # [osx]
- vs2019 # [win]
cxx_compiler:
- gxx # [linux]
- clangxx # [osx]
- vs2019 # [win]
was the only possible choice for C/C++ compilers.
Recently, we finished adding preliminary support clang / clangxx as
C/C++ compilers also on linux and windows, starting from clang 18.
This is still very fresh, so bugs are possible, and we ask not to change
the default compilers on feedstocks unless there are compelling reasons.
In any case, it is now possible to use the following configuration in
recipe/conda_build_config.yaml (note the lack of platform selectors):
c_compiler:
- clang
c_compiler_version:
- 18
cxx_compiler:
- clangxx
cxx_compiler_version:
- 18
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.