Change AstropyDeprecationWarning policy?

@cdeil

Inspired by #6191 and previous related problems, here are some thoughts about deprecation policy for discussion.

It appears the AstropyDeprecationWarning emitted by default. So we get back to the chronic problem of other packages that want to retain support for the last 2 or 3 feature releases of astropy.

To be specific let's say that GammaPy currently uses analytic_functions.black_body_nu and they want the package to work with astropy 1.3 and 2.0. If they change now to use the new modeling function then GammaPy no longer works with astropy 1.3. But if they do not then users that have astropy 2.0 installed will get this warning emitted when black_body_nu is called. In fact this applies to users that have a the current GammaPy installed and then upgrade astropy, at which point when they run they get warnings emitted.

My take on a solution would be:

Make AstropyDeprecationWarning like the standard DeprecationWarning and have it be ignored by default.
Package developers and professional (institutional) developers should be paying attention to release change logs and running CI tests that check for breakage and look for deprecation warnings.
Individual scientists who run their code and don't notice the DeprecationWarning might some day (after a long period of deprecation) notice that their code breaks after upgrading astropy. They will figure this out pretty quickly and fix their code. No problem.
Leave deprecated code in astropy long enough so that other packages can support the current stable and previous 2 feature releases of astropy. I.e. the next release of GammaPy would support astropy 2.0, 1.3, and 1.2.
I might have an off-by-one error, but I think this would imply leaving the deprecated analytic_functions code in astropy for 2.0, 3.0, and 3.1, then removing for 3.2.
Note that astropy LTS versions are no different than regular feature releases from the perspective of a package like GammaPy. They just want to support the last N releases.

cc: @cdeil @astrofrog @eteq

@taldcroft

@taldcroft - If I recall there is a discussion in the related APE, too: astropy/astropy-APEs#20. While gammapy's approach of supporting the last two releases seems reasonable, personally I'm not a big fan of diverting from what we almost agreed on in the APE. Other packages may want to support the last 5, or latest and LTS. Where and how will we draw that line?

@Cadair

(ps. off-topic, but I cannot hold it in: @Cadair @kelle this is one example of discussions that I think can hugely benefit of pyastro providing an opportunity for developers from the wider ecosystem to get together).

Just as a counter-argument to making deprecation warnings invisible by default: in numpy, a removal after 3 releases with a deprecation warning was just reverted because it had not been seen -- not all packages are tested as well as astropy! (numpy/numpy#9251, numpy/numpy#9255)

@mhvk

@mhvk - I'm surprised that even scipy was bitten by that removal, and have to say a big thank you for your efforts to keep us up to date with all the numpy changes!

I don't think we want to hide these warnings by default as users will complain they didn't get warned. As a user, I hate that normal Python deprecation warnings are hidden by default.

is the current system so bad? At the moment, the main burden is on affiliated package maintainers, who have to make sure they release affiliated packages very soon after (or even ahead of) astropy releases to prevent users from seeing deprecation warnings they can't do anything about. In addition, they need to act fast to keep the Travis development builds running if they've opted for failing on deprecation warnings. But at least, things get fixed fast. If we start changing the system, we're going to make it harder for users, whereas I usually prefer making things more difficult for developers (given the choice).

(Also, to be honest this situation is only relevant when we do a new LTS release (and when we start up the new system, e.g. now in 2.0) if we accept the APE addendum).

OK, so to be clear the suggested strategy for affiliated package developers is to handle all astropy deprecations with code that checks astropy version and makes shims as necessary. Is there a nicer way than below? (My editor complains about code before imports, but I guess that is a minor point that I could probably fix somehow).

from astropy.utils import minversion

ASTROPY_LT_2_0 = not minversion('astropy', '2.0')
if ASTROPY_LT_2_0:
    from astropy.analytic_functions import blackbody_nu
else:
    from astropy.modeling import blackbody_nu

Or other fixes as in https://git-cral.univ-lyon1.fr/MUSE/mpdaf/blob/master/lib/mpdaf/tools/astropycompat.py#L30

Anyway, I see the points and am ready to close this.

Yes, I think this is the obvious workaround. Or sometimes I also saw doing the imports in a try/except.

Also for the reverse problem, namely to use new functionalities of astropy, in photutils we've just copied them over to extern and use them from there until we can drop supporting the old versions.

FWIW "except" is expensive if used often. Closing as requested.

@pllim

@pllim - good point, I think @taldcroft's solution is also cleaner, easier to grep for the the ASTROPY_LT_2_0 like strings.

Maybe I should write an astrosix package ? 😁
Just joking of course, but I don't have a better solution than what I use in MPDAF. When it's a new function or a renamed import it's quite easy to write a compatibility module, but for renamed parameters like clobber/overwrite, that is widely used, it's more annoying...

astrosix

Brilliant! But astrosixfivesixthree is more catchy.

As a user, I hate that normal Python deprecation warnings are hidden by default.

Python shot the messenger. PyCapsule was backported to 2.7 and PyCObject deprecated with the result that everyone was spammed with deprecation warnings. So they killed the deprecation warnings. Hey, it worked. Sort of.

for renamed parameters like clobber/overwrite, that is widely used, it's more annoying

Maybe the solution is that for big changes like this, we first emit a PendingDeprecationWarning or at least we warn people one release before we actually deprecate it.

@MSeifert04

"pending" means no warning will be emitted by default, no? Maybe @MSeifert04 can clarify since he added that keyword after people complained about deprecating clobber in 1.3.

@pllim

@pllim No what I did wasn't what is generally understood by PendingDeprecationWarning, I changed the decorator to not emit a Warning at all. 😅

@astrofrog

emit a PendingDeprecationWarning

@astrofrog but then they will complain about seeing a PendingDeprecationWarning warning; Where do we draw the line?

Navigation Menu

Repository navigation

Change `AstropyDeprecationWarning` policy? #6227

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Change AstropyDeprecationWarning policy? #6227

Description

Activity

bsipocz commented on Jun 16, 2017

bsipocz commented on Jun 16, 2017

mhvk commented on Jun 16, 2017

bsipocz commented on Jun 16, 2017

astrofrog commented on Jun 16, 2017

bsipocz commented on Jun 16, 2017

taldcroft commented on Jun 16, 2017

taldcroft commented on Jun 16, 2017

bsipocz commented on Jun 16, 2017

pllim commented on Jun 16, 2017

bsipocz commented on Jun 16, 2017

saimn commented on Jun 16, 2017

pllim commented on Jun 16, 2017

charris commented on Jun 16, 2017

astrofrog commented on Jun 16, 2017

pllim commented on Jun 16, 2017

MSeifert04 commented on Jun 16, 2017

pllim commented on Jun 19, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Change `AstropyDeprecationWarning` policy? #6227