Merge branch 'main' into abi3

Author: larsoner

.github/workflows/deploy.yml

@@ -14,7 +14,7 @@ jobs:
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
 
-      - uses: conda-incubator/setup-miniconda@d2e6a045a86077fb6cad6f5adf368e9076ddaa8d # v3.1.0
+      - uses: conda-incubator/setup-miniconda@505e6394dae86d6a5c7fbb6e3fb8938e3e863830 # v3.1.1
         with:
           python-version: 3.8
           channels: conda-forge
@@ -55,6 +55,8 @@ jobs:
             --exclude 'https://polys.me/?$'
             --exclude 'https://conda-metadata-app.streamlit.app/?$'
             --exclude 'https://kb43fqob7u-dsn.algolia.net/'
+            --exclude 'https://ss64.com/nt/syntax.html'
+            --exclude 'https://www.mesa3d.org/'
             --exclude '.*/404.html/'
             --exclude '.*,.*'
             --exclude-path './build/community/minutes/'

.pre-commit-config.yaml

@@ -15,8 +15,16 @@ repos:
       - id: prettier
         types_or: [markdown, mdx, json, yaml, css, javascript]
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.9.1
+    rev: v0.11.5
     hooks:
       - id: ruff-format
+  - repo: local
+    hooks:
+      - id: sort-csv
+        name: Sort core and emeritus lists
+        entry: scripts/sort_csv.py
+        language: python
+        types: [text]
+        files: src/(core|emeritus)\.csv
 ci:
   autofix_prs: false

LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) 2015-2022, conda-forge
+Copyright (c) 2015-2025, conda-forge
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without

blog/2024-04-02-xz-backdoor.md

@@ -16,7 +16,7 @@ To the best of our knowledge, conda-forge's artifacts for `xz` are _not_ affecte
 
 We immediately checked which `xz` artifacts had been published in our channel:
 
-- Our latest build for `xz` (recipe source available in the [`xz-feedstock`](https://github.com/conda-forge/xz-feedstock/blob/main/recipe/meta.yaml)) is for version `5.2.9` and was uploaded on 2022-12-08. See artifacts in [anaconda.org](https://anaconda.org/conda-forge/xz/files).
+- Our latest build for `xz` (recipe source available in the [`xz-feedstock`](https://github.com/conda-forge/xz-feedstock/blob/8b8001268eb4eb7f9dcab4166ba88926e5ed6e91/recipe/meta.yaml)) is for version `5.2.9` and was uploaded on 2022-12-08. See artifacts in [anaconda.org](https://anaconda.org/conda-forge/xz/files).
 - The backdoored versions of `xz` belong to the `5.6.x` series.
 
 We are monitoring the situation develop and will update this announcement accordingly if needed.

blog/2024-09-26-python-313.md

@@ -4,33 +4,31 @@ authors:
 tags: [infrastructure]
 ---
 
-# Python 3.13 Release candidate builds on conda-forge
+# Python 3.13 builds on conda-forge
 
-conda-forge now supports Python 3.13 release candidates on conda.
+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/label/python_rc -c conda-forge
+    conda create -n py313 python=3.13 -c conda-forge
 
 <!-- truncate -->
 
 This will create a new environment with Python 3.13 with the global
 interpreter lock (GIL) enabled. A migration is underway that builds
 Python extensions like those included in `numpy` and `scipy` as conda packages. The migration
-is [55% complete](/status/migration/?name=python313) at the time of writing. Once the first final release of
-`python` 3.13 is available the `python_rc` label will not be needed
-anymore.
+is [55% complete](/status/migration/?name=python313) at the time of writing.
 
 New in this Python release is the `python-freethreading` build which
 removes the GIL and enables free threading. To install a `freethreading`
 build, you can do:
 
-    conda create -n py313 python=3.13 python-freethreading -c conda-forge/label/python_rc -c conda-forge
+    conda create -n py313 python=3.13 python-freethreading -c conda-forge
 
 Analogous to this package we also have a metapackage to explicitly
 install the GIL variant:
 
-    conda create -n py313 python=3.13 python-gil -c conda-forge/label/python_rc -c conda-forge
+    conda create -n py313 python=3.13 python-gil -c conda-forge
 
 Note that there are no conda packages for freethreading Python extensions yet and
 we hope to start a migration for freethreading extensions in the

blog/2024-10-15-python-noarch-variants.md

@@ -0,0 +1,124 @@
+---
+authors:
+  - isuruf
+tags: [infrastructure]
+---
+
+# Noarch variant packages for Python packages on conda-forge
+
+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.
+
+<!-- truncate -->
+
+conda-forge packages have always been batteries included. When
+a package has some build options turned off by default to reduce
+dependencies, we have enabled these options to give the most
+functionality and performance to our users.
+
+In the Python world, some packages are written in C/C++/Cython
+to get the most performance out of a package. However these packages
+sometimes have a reference implementation written in Python. The Python
+reference implementation is a good way to check the C/C++/Cython
+code against a much simpler python implementation and is also
+useful for platforms like PyPy where the C/C++/Cython implementation
+can be slower than the Python reference implementation due to the
+emulation of the Python C/C++ API by PyPy. For example for the Cython
+package, setting the `CYTHON_NO_COMPILE` environment variable
+when building the Cython wheel itself, it will use the Python reference
+implementation. The only way to figure out if a package has a Python
+reference implementation is to look at the library's source code
+to see if `extensions` are optional.
+
+To support platforms like PyPy, some packages build wheels with
+compiled extensions for the platforms that are
+known to be more performant with the compiled extension, but also
+provide a universal pure Python wheel for the other platforms.
+This also provides a way for new Python versions and variants
+like the free-threading Python build to use these packages by the
+early adopters of these Python versions.
+
+On conda-forge we usually have compiled Python packages, but provide
+no reference implementation. This means early adopters of new Python
+versions need to wait for the conda-forge bot managed by @conda-forge/bot
+team to start the migration and rebuild the packages. For example the
+free-threading Python 3.13 build is still paused as
+conda-forge has decided to focus on the default (GIL enabled)
+Python 3.13 build first while upstream packages work on
+supporting free-threading.
+Another issue is that some packages have cyclic dependencies at build
+or test time and this requires some manual handling.
+
+We have been adding `noarch: python` variants for some feedstocks
+so that the compiled extension has higher priority and the pure
+Python extension has lower priority, which makes the conda solver
+use the `noarch: python` variant if no suitable compiled variant
+is available. One issue is that the linter might not like selectors
+on noarch recipes. We added an option
+
+```yaml
+linter:
+  skip:
+    - lint_noarch_selectors
+```
+
+to `conda-forge.yml` that will make the linter skip this warning/error.
+
+We build the two variants using a `recipe/conda_build_config.yaml`
+with the contents,
+
+```yaml
+use_noarch:
+- true       # [linux64]
+- false
+```
+
+Then in `recipe/meta.yaml` we make the following changes
+
+```yaml
+build:
+  noarch: python           # [use_noarch]
+  track_features:          # [use_noarch]
+    - pyyaml_no_compile    # [use_noarch]
+
+requirements:
+  build:
+    - {{ compiler('c') }}
+    - {{ stdlib("c") }}
+  host:
+    - python                        # [not use_noarch]
+    - python {{ python_min }}.*     # [use_noarch]
+    - setuptools
+    - pip
+  run:
+    - python                        # [not use_noarch]
+    - python >={{ python_min }}.*   # [use_noarch]
+    - yaml
+
+test:
+  requires:
+    - pip
+    - python {{ python_min }}.*     # [use_noarch]
+```
+
+Finally in the build script, we use the env variable `use_noarch`
+to set an option to force the extension to be pure python.
+In the case of pyyaml, we can force that by setting the env variable
+`PYYAML_NO_LIBYAML`. A `recipe/build.sh` might look like,
+
+```bash
+if [[ "$use_noarch" == "true" ]]; then
+  export PYYAML_NO_LIBYAML=1
+fi
+$PYTHON -m pip install .
+```
+
+We list some PRs here as a reference for conda-forge maintainers who
+want to experiment.
+
+- [pyyaml](https://github.com/conda-forge/pyyaml-feedstock/pull/55)
+- [coverage](https://github.com/conda-forge/coverage-feedstock/pull/123)
+- [cython](https://github.com/conda-forge/cython-feedstock/pull/147)
+- [aiohttp](https://github.com/conda-forge/aiohttp-feedstock/pull/99)

blog/2025-02-27-conda-forge-v1-recipe-support.md

@@ -0,0 +1,101 @@
+---
+authors:
+  - wolfv
+tags: [infrastructure]
+---
+
+# Announcing the new recipe format on conda-forge
+
+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.
+
+<!--truncate-->
+
+## rattler-build and the v1 spec
+
+The v1 recipe format has a number of benefits:
+
+- It always parses as valid YAML which makes it much easier to modify it with the bot infrastructure of conda-forge. While meta.yaml looks like YAML, it can contain Jinja logic that is incompatible with the YAML specification, which significantly complicates parsing and automated manipulation. Additionally, the new recipe format has [a published JSON schema](https://github.com/prefix-dev/recipe-format/blob/main/schema.json) which means that the editing experience in VS Code is greatly improved with contextual help.
+- The new recipe format enables much faster builds due to design decisions that eliminate the need for recursive parsing.
+- Some features of conda-build, such as multiple outputs, had a lot of implicit behavior. We are fixing that in the v1 recipe.
+
+conda-forge uses rattler-build as its default build tool for the v1 recipe format. rattler-build currently has some significant benefits:
+
+- rattler-build is built on top of rattler, a modern re-implementation of the conda standards in Rust, enabling extremely fast recipe builds.
+- The log output of rattler-build is greatly improved, always showing the user what the final files in the package are and the final metadata.
+
+You can read much more about the v1 recipe format in the [https://rattler.build](https://rattler.build) docs and the two CEPs [CEP-0013](https://github.com/conda/ceps/blob/main/cep-0013.md) and [CEP-0014](https://github.com/conda/ceps/blob/main/cep-0014.md). With the new format comes also a new build tool called [`rattler-build`](https://github.com/prefix-dev/rattler-build) which is developed by [`prefix.dev`](https://prefix.dev). It is a reimplementation of conda-build in Rust, on top of the [`rattler`](https://github.com/conda/rattler) libraries.
+
+A simple v1 recipe looks something like the following:
+
+```yaml
+context:
+  # we define named variables in the context instead of `{$ set ... %}` directives
+  version: "23.0.0"
+
+package:
+  name: "boltons"
+  # note that we use "GitHub" inspired syntax to access context / Jinja variables
+  version: ${{ version }}
+
+source:
+  url: https://github.com/mahmoud/boltons/archive/refs/tags/${{ version }}.tar.gz
+  sha256: 9b2998cd9525ed472079c7dd90fbd216a887202e8729d5969d4f33878f0ff668
+
+build:
+  noarch: python
+  script:
+    - python -m pip install . --no-deps -vv
+
+requirements:
+  host:
+    - python
+    - pip
+    - setuptools
+  run:
+    - pip
+
+about:
+  license: BSD-3-Clause
+  license_file: LICENSE
+```
+
+## How to use the v1 recipe format on conda-forge
+
+If you are adding a new recipe on staged-recipes, then it's easy: just submit a `recipe.yaml` file instead of a `meta.yaml` file.
+In case you already maintain a feedstock, then the conversion can be semi-automated with a tool created by [Hadrien Mary](https://github.com/hadim) called [`feedrattler`](https://github.com/hadim/feedrattler). The tool will take care of the basic conversions steps and uses [`conda-recipe-manager`](https://github.com/conda-incubator/conda-recipe-manager) by Anaconda / [Schuyler Martin](https://github.com/schuylermartin45) under the hood to parse the recipe and convert it to the new format.
+
+```shell
+# One liner with Pixi
+pixi exec feedrattler my-awesome-package-feedstock gh_user
+# With conda or mamba (as $CONDA)
+$CONDA create -n feedrattler feedrattler
+$CONDA activate feedrattler
+feedrattler my-awesome-package-feedstock gh_user
+```
+
+To do the conversion by hand, you need to do the following things:
+
+- In the feedstock's `conda-forge.yml`, add `conda_build_tool: rattler-build`
+- Remove the `meta.yaml` file and add a `recipe.yaml` file following the v1 spec
+- Rerender the feedstock using `conda-smithy rerender`
+- Push your changes to your fork and open a PR to see the CI build your package
+
+## Transition plans
+
+For the foreseeable future, conda-forge is going to support both formats, v1 and v0. We envision a gradual transition over at least one year to the new spec. There are a couple of places where the v1 spec also needs to finalize / stabilize. One notable place is the `cache`-based multi-output feature, where CEP discussions are ongoing. This stabilization in the format should happen within Q1 of 2025.
+
+Since the beginning of 2025, the bot has gained more capabilities for the v1 format, such as automatically bumping versions (the "autotick-bot"). There are a number of other migrators and mini-migrators that need to be fully ported to the v1 spec before we can claim 100% compatibility with the conda-forge infrastructure.
+
+As of today, over 700 of the 25000 recipes on conda-forge have been converted.
+
+For now, the recommendation on staged-recipes is: if it's a simple `noarch: python` recipe, it should probably be a `v1` recipe. The same goes for `Rust` or `Go` projects that have a simple structure.
+
+### Where to learn more
+
+There are very helpful docs located at [https://rattler.build](https://rattler.build) that explain the differences of the new recipe format pretty well. You are also very welcome to chat with us on the [conda-forge Zulip](https://conda-forge.zulipchat.com/), or chat with the rattler-build developers on [their Discord](https://discord.gg/kKV8ZxyzY4).
+
+You can also read more about rattler-build and the v1 format in the following blog posts:
+
+- https://prefix.dev/blog/rattler_build_on_conda_forge
+- https://prefix.dev/blog/the_love_of_building_conda_packages
+- https://prefix.dev/blog/rattler_build_a_new_parser

blog/2025-04-02-security-incident-with-package-uploads.md

@@ -0,0 +1,50 @@
+---
+authors:
+  - core
+tags: [security]
+---
+
+# Security Incident with Package Uploads (CVE-2025-31484)
+
+In the past few months, `conda-forge` has been engaging with an external security audit in collaboration with
+the [Open Source Technology Improvement Fund](https://ostif.org/) (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](https://github.com/conda-forge/infrastructure/security/advisories/GHSA-m4h2-49xf-vq72)
+for more details.
+
+<!-- truncate -->
+
+We have requested a CVE from GitHub and will amend this announcement once it is issued. Our response to this
+incident is detailed below, but TL;DR, as best as can reasonably be determined, **no packages were compromised
+during this time**.
+
+Thank you for using `conda-forge`, please [contact us](https://conda-forge.org/community/getting-in-touch/) if you
+have further questions, and please follow our [security process](https://github.com/conda-forge/conda-forge.github.io/blob/main/SECURITY.md)
+for responsible reporting of vulnerabilities.
+
+**Finally, as a reminder, `conda-forge` packages are built by strangers on the internet (our wonderful feedstock
+maintainers!) and are not suitable for use cases that require secure software provenance.**
+
+## Response timeline
+
+The timeline and details of our response to this security incident are as follows:
+
+- 2025-04-01 13:35 UTC: OSTIF and their contractor notified `conda-forge` of the leaked token.
+- 2025-04-01 14:00 UTC: The `conda-forge/core` team acknowledged receipt of the report and
+  started conducting the investigation.
+- 2025-04-01 14:15 UTC: The `conda-forge/core` team disabled the token and stopped uploads to `anaconda.org`.
+- 2025-04-01 14:20 UTC: We posted an [incident](https://github.com/conda-forge/status/issues/194)
+  to our status page reporting that uploads were temporarily paused.
+- 2025-04-01 15:19 UTC: We audited all uploads to the `conda-forge` channel, looking for uploads that
+  bypassed our upload staging process. We did not find any. This check is not completely robust, but it
+  does indicate that nothing was obviously compromised.
+- 2025-04-01 15:53 UTC: We decided to delay disclosure by one day to 2025-04-02 in order to not generate
+  confusion (2025-04-01 is [April Fools' Day](https://en.wikipedia.org/wiki/April_Fools%27_Day) in some countries
+  when people commonly engage in practical jokes).
+- 2025-04-01 21:39 UTC: We deployed a fix to our infrastructure.
+- 2025-04-01 22:20 UTC: We then deployed a new token to our infrastructure and restarted uploads.
+- 2025-04-01 23:02 UTC: The status page [incident](https://github.com/conda-forge/status/issues/194) was marked as resolved.
+- 2025-04-02: We published this announcement and the advisory. GitHub produced CVE-2025-31484 for us based on our security advisory.