pytest triggering deprecation warnings in 3.0.5

[nicoddemus]

As commented by @nedbat in https://bitbucket.org/ned/coveragepy/pull-requests/94, it seems pytest itself is making use of the deprecated compatproperty names:

/Users/ned/coverage/trunk/.tox/py27/lib/python2.7/site-packages/_pytest/fixtures.py:1071: PendingDeprecationWarning: This usage is deprecated, please use pytest.Class instead
  obj = getattr(holderobj, name, None)
/Users/ned/coverage/trunk/.tox/py27/lib/python2.7/site-packages/_pytest/fixtures.py:1071: PendingDeprecationWarning: This usage is deprecated, please use pytest.File instead
  obj = getattr(holderobj, name, None)
/Users/ned/coverage/trunk/.tox/py27/lib/python2.7/site-packages/_pytest/fixtures.py:1071: PendingDeprecationWarning: This usage is deprecated, please use pytest.Function instead
  obj = getattr(holderobj, name, None)
/Users/ned/coverage/trunk/.tox/py27/lib/python2.7/site-packages/_pytest/fixtures.py:1071: PendingDeprecationWarning: This usage is deprecated, please use pytest.Instance instead
  obj = getattr(holderobj, name, None)
/Users/ned/coverage/trunk/.tox/py27/lib/python2.7/site-packages/_pytest/fixtures.py:1071: PendingDeprecationWarning: This usage is deprecated, please use pytest.Item instead
  obj = getattr(holderobj, name, None)
/Users/ned/coverage/trunk/.tox/py27/lib/python2.7/site-packages/_pytest/fixtures.py:1071: PendingDeprecationWarning: This usage is deprecated, please use pytest.Module instead
  obj = getattr(holderobj, name, None)

cc @nmundar

[RonnyPfannschmidt]

this may prove tricky, it happens in parse_factories

[nedbat]

Couldn't you put a "with warnings.catch_warnings():" around line 1071? https://docs.python.org/3/library/warnings.html#temporarily-suppressing-warnings

[RonnyPfannschmidt]

i'd rather investigate why we run into those objects, and whether we can avoid the situation to begin with (as we could be hiding other deprecations as well)

[nedbat]

A quick test in my tox virtualenv seems to show that the context manager doesn't prevent the warnings..?

BTW, I run my test suite with:

# We want to see all warnings while we are running tests.  But we also need to
# disable warnings for some of the more complex setting up of tests.
warnings.simplefilter("default")

# Silence specific warnings that are not our fault.
warnings.filterwarnings("ignore", module="xdist", message="type argument to addoption")

So I try to see warnings, but that last line is to suppress a warning that pytest-xdist causes.

[nedbat]

Oops, I hadn't tried catch_warnings correctly. This works, and should only silence this specific warning:

with warnings.catch_warnings():
    warnings.filterwarnings("ignore", message="This usage is deprecated, please use pytest.* instead")
    obj = getattr(holderobj, name, None)

[RonnyPfannschmidt]

@nedbat if i recall correctly that operation will reset the once filter cache of the warnings module in various python version

[RonnyPfannschmidt]

@nedbat the real bug is, that it tries to operate on a Node object as test object

[RonnyPfannschmidt]

@nicoddemus @nedbat the problem lies in _pytest/python.py:360 - getcustomclass triggers this

i will fix this one

[The-Compiler]

I can confirm this, breaks my testsuite since I use -Werror 😉

Bisected to b38fad4 - cc @nmundar

[nicoddemus]

After @RonnyPfannschmidt fixes it, should we do a 3.0.6 release or it can wait a few weeks?

[RonnyPfannschmidt]

@The-Compiler you should never error on pending ones tho ^^

[The-Compiler]

I just blacklisted 3.0.5, so no hurry from my side.

@RonnyPfannschmidt I'll have to disagree - if pytest failed on PendingDeprecationWarnings in its testsuite, I'm pretty we'd have noticed that it's issuing them during normal operation. And in my own testsuite, IMHO it's good to know about deprecated stuff as early as possible 😉

[RonnyPfannschmidt]

@The-Compiler pendingdeprecations are really silent by default

also while investigating we added pending deprecation in a really bad way
i put a real deprecation there because it should fail hard on this one since a while (namely 2.x)

[The-Compiler]

DeprecationWarnings are also silent by default 😉

Your PR still does PendingDeprecationWarning though, right? FWIW I don't think we should change that to a DeprecationWarning with a patch release.

[RonnyPfannschmidt]

i still do the pending ones for the old usage site, i changed the other usage side that uses a old api to log the deprecation

[rgant]

Wish I'd known about this error before I upgraded pytest to 3.0.5. I don't think that 3.0.5 should be available without this issue resolved. I guess I'm going to figure out how to downgrade my pytest install.

[The-Compiler]

I haven't really had time for much pytest work recently, and just happened to rediscover today that I blacklisted pytest 3.0.5 for qutebrowser 😆

Judging from the commits referencing this issue, others did the same - so I think this should really be fixed for a 3.0.6.

[RonnyPfannschmidt]

i have a related pr in the work, it will be fixed by 3.0.6

[The-Compiler]

I agree with @nicoddemus (this comment and the following ones) that we should rather revert patch-level deprecations and deprecate things properly for the next feature release.

[RonnyPfannschmidt]

@The-Compiler the triggering deprecation will be removed, there is an original deprecation that simply doesnt cause warnings that i want to ressurrect at the same time

[nicoddemus]

IMHO just moving the deprecation that was introduced to the features branch is enough, no need to ressurect the other deprecation because I suspect users don't see it anyway.