Get --debug flag from sys.argv instead of using an astropy helpers routine

[astrofrog]

This is a self-contained subset of changes related to the APE A roadmap for package infrastructure without astropy-helpers. This PR as-is is ready for review, and does not actually require removing astropy-helpers to work, though I think we should maybe wait until Tuesday to merge since that's when we'll be discussing the APE in Socorro.

Previously, the presence of the --debug flag to setup.py was used to control whether certain warnings should be shown or not when compiling the io.fits and wcs extensions. For similar reasons to #9730 it makes more sense to switch to using an environment variable to control this. Note that this is not a documented feature, hence why there are no changes to the docs.

I'm not super happy with the variable name so far, so am open to other suggestions - @mhvk?

EDIT: changed to getting --debug from sys.argv

[pllim]

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

[mhvk]

Maybe ASTROPY_SHOW_ALL_COMPILATION_WARNINGS (or maybe with _ALL?)

Changes look good otherwise.

[astrofrog]

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?

[mhvk]

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;

[astrofrog]

@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?

[mhvk]

I like the name, and it all looks good.

[saimn]

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.

[mhvk]

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.

[astrofrog]

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?

Continuing discussion about approach

[mhvk]

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...)

[astrofrog]

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.

[mhvk]

Super, let's go this way!

[mhvk]

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

[astrofrog]

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

[astrofrog]

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.

[astrofrog]

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

[astrofrog]

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.