From 86c56a150636f2b876a9ec152ab0e785657f62d7 Mon Sep 17 00:00:00 2001 From: Isuru Fernando Date: Mon, 21 Oct 2024 08:44:21 -0400 Subject: [PATCH] Apply suggestions from code review Co-authored-by: jakirkham --- blog/2024-10-15-python-noarch-variants.md | 24 +++++++++++------------ 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/blog/2024-10-15-python-noarch-variants.md b/blog/2024-10-15-python-noarch-variants.md index 72aec6fd08..c26fa1bd02 100644 --- a/blog/2024-10-15-python-noarch-variants.md +++ b/blog/2024-10-15-python-noarch-variants.md @@ -25,13 +25,12 @@ 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 eg: for the Cython +emulation of the Python C/C++ API by PyPy. For example for the Cython package, setting `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 `setup.py` on packages that -provide such a file to see if `extensions` are built always or -with a switch. +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 @@ -42,16 +41,15 @@ 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 makes early adopters of new Python -versions to wait for the conda-forge bot managed by @conda-forge/bot -team to start the migration and rebuild the packages. For eg: the -free-threading Python 3.13 build is still not under way because -conda-forge has decided to wait until the default (GIL enabled) -Python 3.13 build has migrated enough and upstream packages have added -support for free-threading builds. +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 manual handling to reduce dependencies -before the migration and add the dependencies later on. +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