Difficulty suppressing deprecation warnings

[jaraco]

In jaraco/skeleton#57, I collected four different issues that pytest 7 introduced in the plugins I use across my projects.

In one of the plugins, I fixed the issue promptly, because I own it. In the others, I expect slower progress, so I've attempted to suppress the DeprecationWarnings by adding to the pytest config (jaraco/skeleton@8949d1a). Unfortunately, I realized later that it's not possible to specify the warning category on Pytest 6 because it doesn't exist yet.

As a result, all of my projects are now currently incompatible with pytest prior to version 7.

I'm not sure how to handle this situation. I can think of some options, none of which are great:

• Remove the warning category and rely solely on the message.
• Write a plugin that adds the filter(s) programmatically and conditional on the pytest version.
• Require pytest 7.
• Stop using those plugins altogether.

Tangentially related, the use of a version number in a deprecation warning seems like a bad idea to me. It (a) requires a new exception for each major version, and (b) more importantly, it commits the project to deprecating this set of functionality in a particular pytest version. I agree it's nice to have some predictability and visibility into the roadmap for pytest, but I've been bitten in the past by anticipating a version in which a change will occur only to find that that change didn't occur or couldn't occur as predicted, so the advertisement becomes false. I'd advise instead to commit to a minimum lifetime for a deprecated feature (e.g. 6 months), perhaps aligned with the anticipated release cadence, but not commit specifically to removing it until the code is actually removed.

Back to my original problem, this issue would have been easier to deal with if a general warning category had been used, one that's been around for some time (either in the stdlib or in pytest).

Do you have any better ideas than the ones described above for addressing this concern?

[The-Compiler]

From the changelog:

#7480: A deprecation scheduled to be removed in a major version X (e.g. pytest 7, 8, 9, …) now uses warning category PytestRemovedInXWarning, a subclass of PytestDeprecationWarning, instead of PytestDeprecationWarning directly.

So I'm assuming you could use PytestDeprecationWarning as category filter instead.

Tangentially related, the use of a version number in a deprecation warning seems like a bad idea to me. It (a) requires a new exception for each major version, and (b) more importantly, it commits the project to deprecating this set of functionality in a particular pytest version.

I don't think anyone would mind if a deprecation gets postponed. FWIW Django uses the same system we do, and I think I've seen it in many other projects too.

[jaraco]

So I'm assuming you could use PytestDeprecationWarning as category filter instead.

Yes! That works perfectly. I've been bitten by warnings filters so many times, I was far from confident that the class hierarchy would work as one might expect, but it does, so that solves the issue, and in an elegant way.

I don't think anyone would mind if a deprecation gets postponed. FWIW Django uses the same system we do, and I think I've seen it in many other projects too.

Right, so if one of these deprecations get postponed, it not only causes toil that the exception needs to get updated (PytestRemovedIn8Warning -> PytestRemovedIn9Warning), but anyone depending on that specific category will need to update. That said, with the above solution, once someone knows to translate PytestRemovedInXWarning to PytestDeprecationWarning, it's much easier to manage, so feel free to continue with the approach as it is apparently providing some value.