Env var is no fun on Windows, but I guess it is a small price to pay for simplification, so 👍

Maybe ASTROPY_SHOW_ALL_COMPILATION_WARNINGS (or maybe with _ALL?)

Changes look good otherwise.

If we want we could actually add back command-line flags in setup.py that sets the env var automatically, but maybe let's not do that first and do it if anyone needs it?

I had been wondering about being able to set defaults in setup.cfg, but felt one should do it only if there is some standard, commonly accepted approach. For now, probably best to just make the simplification;

@mhvk - I like your suggestion for the variable name but then I thought maybe ASTROPY_VERBOSE_COMPILATION_WARNINGS could work too and require fewer words. What do you think?

Not sure about this one: --debug is not some custom option from astropy, it is a setuptools thing. And I think it makes sense to not hide these warnings when compiling in debug mode with this setuptools option, without having to know that these is another env var to activate.

Ah, so --debug actually does do a lot more!? If we do not need anything from astropy-helpers to use it, then I agree it makes more sense to just stick with what we have.

Yes indeed --debug is a setuptools option but I can't find a clean way to find out if that option is present without having to have some hackery as currently done in astropy-helpers. If there is a standardized way to get this option, then I'm all for it, but otherwise I think we have to find a different way as done here. I suppose we could imagine also just checking for the presence of the --debug flag in sys.argv in setup_package.py files?

I wasted the better part of an hour only to come to your conclusion, that the --debug option is not much exposed at all. I think for this corner case I'd be quite happy with something like
if '-g' in sys.argv or '--debug' in sys.argv

p.s. As far as I can see, --debug does actually rather little, mostly just compiling in a different directory and adding a -g flag (which is there by default anyway...)

Ok I've updated this to look for --debug in sys.argv. I didn't check for -g since it may be there by default in some cases and I think we really should just check for an explicit --debug.

The failure seems unrelated but real. Maybe a rebase is needed?

This is already rebased, very confused by the failure...

It's a race condition because two doctests are using the filename values.dat (the 32-bit build is also the parallel build). I think we should not include that fix here though since that will likely need to be backported. I'll open a separate PR.

See #9800 for the (unrelated) 32-bit failure.

I'm going to go ahead and merge this since it was approved and the 32-bit failure is unrelated - and APE 17 has been merged.