Repository navigation
Change AstropyDeprecationWarning policy? #6227
Description
Activity
@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?
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)
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_nuOr 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
externand use them from there until we can drop supporting the old versions.FWIW "except" is expensive if used often. Closing as requested.
@pllim - good point, I think @taldcroft's solution is also cleaner, easier to grep for the the
ASTROPY_LT_2_0like strings.Reacted by P. L. LimMaybe I should write an
astrosixpackage ? 😁
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 likeclobber/overwrite, that is widely used, it's more annoying...Reacted by P. L. Limastrosix
Brilliant! But
astrosixfivesixthreeis more catchy.As a user, I hate that normal Python deprecation warnings are hidden by default.
Python shot the messenger.
PyCapsulewas backported to 2.7 andPyCObjectdeprecated with the result that everyone was spammed with deprecation warnings. So they killed the deprecation warnings. Hey, it worked. Sort of.Reacted by Thomas Robitaille and P. L. Limfor 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.
"pending" means no warning will be emitted by default, no? Maybe @MSeifert04 can clarify since he added that keyword after people complained about deprecating
clobberin 1.3.@pllim No what I did wasn't what is generally understood by
PendingDeprecationWarning, I changed the decorator to not emit a Warning at all. 😅Reacted by P. L. Limemit a PendingDeprecationWarning
@astrofrog but then they will complain about seeing a
PendingDeprecationWarningwarning; Where do we draw the line?
Inspired by #6191 and previous related problems, here are some thoughts about deprecation policy for discussion.
It appears the
AstropyDeprecationWarningemitted 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_nuand they want the package to work with astropy 1.3 and 2.0. If they change now to use the newmodelingfunction 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 whenblack_body_nuis 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:
AstropyDeprecationWarninglike the standardDeprecationWarningand have it be ignored by default.cc: @cdeil @astrofrog @eteq