Make it configurable to skip subset of deprecations being raised

Under python3.6 we see this issue that using unittest with pytest is raising tons of DeprecationWarnings (e.g. astropy/halotools#718 & astropy/astroquery#815)

It would be rather useful to have a configurable list for treat_deprecations_as_exceptions that would skip deprecations being raised, similarly as it already happens for a few packages by default:
https://github.com/astropy/astropy/blob/master/astropy/tests/helper.py#L242

I'm adding a milestone, so if noone else picks this up I'll try to do it myself for the next major release.

Also if this happens before, I'm considering this backporting to a bugfix, as this missing feature may be considered a bug (as the tests are failing in the affiliates).

For the StopIteration error, wouldn't it be more proper to address the underlying problem?

https://www.python.org/dev/peps/pep-0479/#writing-backwards-and-forwards-compatible-code

To me it seems to be an issue upstream, but happy to change local code if it turn out to be a false assumption (except that in astroquery we need to get rid of unittest altogether as it only adds an extra layer of unnecessary complexity).

Upstream where? In Astropy test helper? Since PEP 479 is accepted, this seems like a real deprecation, not a bug.

In pytest? (I have to admit that I didn't have time to properly dig into this, but we see this in multiple packages, and when both using unittest and pytest. Quite unlikely that both packages are doing something wrong, but certainly not impossible.)

Or maybe we're seeing it as we're using the astropy bundled old pytest? If the latter, this becomes a very good reason to finally get rid of it from core.

The deprecation itself stemmed from how iterator works in Python. And since Astropy's CI is not complaining about this deprecation, it is likely that the offending piece of code is either:

In the package template that everyone follows but not Astropy.
A piece of code in test helper that Astropy somehow does not use but affiliate does.
In the affiliated package itself. It could be that affiliated packages borrowed test codes from each other or shared developers and hence run into the same warning.

@pllim

@pllim - astropy core doesn't use unittest as these package do.

And staying on topic, independently of this specific failure, I think it would be useful to have a control over which packages get silenced their DeprecationWarnings and which not.

Re: on topic. I just don't think it is a good idea to enable such a thing. It is going to come back and bite us when we silence something and then forget about it.

Well, we already silence a few e.g. scipy, in a rather blackbox like manner from the affiliates point of view. Having these listed as defaults in the conftest.py would make things a little bit clearer I think.

@pllim

@pllim - Off-topic: You were right that this got fixed upstream. We only saw it as we were still using the astropy bundled pytest in both packages. After wwitching to use system pytest (pytest3) there are no deprecation warnings.

@bsipocz

@bsipocz , I think the credit to me is undue, as you were the one who suggested the upstream issue was in pytest, see #5917 (comment) 😉

@pllim

Thanks @pllim. Many of the config stuff is defaulted in astropy (e.g. the dictionary PYTEST_HEADER_MODULES), but affiliates can override it in their conftest. So maybe a similar approach could work here, too.

actually #6223 only addressed part of this issue I mean (though the description was a bit sloppy). E.g. these reproject tests are failing as pytest-arraydiff is not yet updated to remove the deprecated usage of astropy. The current solution only makes it possible to ignore packages that raises deprecation warnings upon import, but not when being used.

https://travis-ci.org/astrofrog/reproject/jobs/230737026#L866

Would be nice to be able to ignore all the warnings that come from a package.

Theoretically, something like #6223 can be extended to also ignore all deprecation warnings from given module(s). Something like:

_warnings_to_ignore_entire_module = set([])

def enable_deprecations_as_exceptions(..., warnings_to_ignore_entire_module=[]):
    ...
    global _warnings_to_ignore_entire_module
    _warnings_to_ignore_entire_module.update(warnings_to_ignore_entire_module)

def treat_deprecations_as_exceptions():
    ...
    for m in _warnings_to_ignore_entire_module:
        warnings.filterwarnings('ignore',  category=DeprecationWarning, module=m)

oh, that would be great! I stated to debug this to come up with something sensible, but the got side tracked. Probably can come up with something in the upcoming days, unless you get there first.

Probably can come up with something in the upcoming days, unless you get there first.

What I wrote there is exactly how I would implement it. I just need to squeeze out an hour or so to come up with a proper PR. Hopefully in a few hours. 😉

Should we then threat it as a bugfix? 😉

bugfix?

Sure, if you don't mind the backporting. 😄

@eteq

Backporting is easy, the question whether this can lay low under @eteq's radar. But nevertheless it's a super useful addition for affiliates to use straight away, thus I would consider it to backport.

@bsipocz

@bsipocz , does #6334 work for your use case?

Sadly not, but I'll test it further once get home.

Navigation Menu

Repository navigation

Make it configurable to skip subset of deprecations being raised #5917

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Make it configurable to skip subset of deprecations being raised #5917

Description

Activity

pllim commented on Mar 28, 2017

bsipocz commented on Mar 28, 2017

pllim commented on Mar 28, 2017

bsipocz commented on Mar 28, 2017

pllim commented on Mar 28, 2017

bsipocz commented on Mar 28, 2017

bsipocz commented on Mar 28, 2017

pllim commented on Mar 28, 2017

bsipocz commented on Mar 28, 2017

bsipocz commented on Mar 29, 2017

pllim commented on Mar 29, 2017

4 remaining items

bsipocz commented on Jun 15, 2017

bsipocz commented on Jul 4, 2017

pllim commented on Jul 4, 2017

bsipocz commented on Jul 4, 2017

pllim commented on Jul 5, 2017

bsipocz commented on Jul 5, 2017

pllim commented on Jul 5, 2017

bsipocz commented on Jul 5, 2017

pllim commented on Jul 5, 2017

bsipocz commented on Jul 5, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions