Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the test.requires section of recipe, you should usually use python {{ python_min }} for the python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13557861247. Examine the logs at this URL for more detail.}

Note that the CFLAGS changes may affect builds within conda-forge, because the flags with which CPython itself builds are no longer inherited (semantics changed from "append" to "overwrite").

Yeah this is a likely going to be a surprising change for some. In what cases, how visible, etc. am not sure

For others coming by here, please see these upstream refs:

• [BUG] setuptools 75.7.0 and CFLAGS pypa/setuptools#4836
• Use CFLAGS if set as-is, match CXXFLAGS behavior pypa/distutils#322

Probably thing for builds to do (borrowing your syntax Ralf) is something like this

export CFLAGS=$(python -c "import sysconfig; print(sysconfig.get_config_var('CFLAGS'))")

Probably thing for builds to do (borrowing your syntax Ralf) is something like this

Yes either that, or figure out what's actually needed and use it as an opportunity to fix the problem that is being turned up by a build failure.

Given how tightly we align CFLAGS in conda-forge, probably the first step is making sure they match. Certainly there are cases where tweaking a flag is needed

Have also mentioned this in Zulip to help raise awareness

Let's mark this release as broken.

use it as an opportunity to fix the problem that is being turned up by a build failure.

Without the workaround, even -O2 is not passed to the build and would lead to non-optimized builds.

Sorry. What? Are you seriously telling me you don't pass -O2 for all the many build systems other than setuptools? Like the ones for C/C++ libraries? Many of which have used build systems for the past twenty-some-odd years with the exact same "overwrite" behavior that setuptools is late to the party with?

We do when conda packages are being built, but conda packages are used for building locally as well which is where we don't set CFLAGS.

Note that the CFLAGS changes may affect builds within conda-forge, because the flags with which CPython itself builds are no longer inherited (semantics changed from "append" to "overwrite").

Yeah this is a likely going to be a surprising change for some.

So is this not accurate, then? Which is it? :)

It may affect builds within conda-forge. 99% of cases it won't, but there would be corner cases where it would be.
It will affect builds using setuptools.

It may affect builds within conda-forge. 99% of cases it won't, but there would be corner cases where it would be.
It will affect builds using setuptools.

I can't yet think of concrete cases where it will go wrong, but I agree that there will be some corner cases. I thought it'd be useful to smoke those out the sooner the better.

We do when conda packages are being built, but conda packages are used for building locally as well which is where we don't set CFLAGS.

Fewer things in CFLAGS et al. for local builds would be better. There's only a single thing that really needs to be in there, which is -isystem /path/to/prefix/include/. Everything else tends to cause more problems than it solves. And -O2 is already in CFLAGS from compiler activation scripts anyway (bad).

Let's mark this release as broken.

I'm fine with marking this release as broken and blocking merges of further setuptools releases on this issue for a while if you prefer, to see if anything changes upstream or let problems be sorted out elsewhere first. But if it doesn't change upstream, sooner or later we have to follow suit here.

Did we get some user reports somewhere? What are the issues they are seeing?