Backward compatibility of pytest 7.2.0 and import py.test

[frenzymadness]

I'm not sure whether this is a bug or not but because changelog says that pytest follows semantic versioning, it might be a bug/regression. I'm testing pytest 7.2.0 with couple hundreds of RPM packages in Fedora Linux and it turned out that some of them are using py.test instead of pytest in their tests. For example rply or notario. But you can find more via grep.app.

This worked because of this file: https://github.com/pytest-dev/py/blob/master/py/test.py

I don't know how this can be workarounded in the py.py module but having something in py package raising a deprecation warning first for some time would be great.

[asottile]

py.test while discouraged, has not been removed:

pytest/setup.cfg

Line 66 in 50b232b

py.test=pytest:console_main

[nicoddemus]

Perhaps we need to include a py.test which points to pytest in our py workaround, preferably it somehow raising a deprecation warning?

cc @asottile

[nicoddemus]

Note that the problem is not the entry point, but code which does this:

import py

try:
    from rpython.rtyper.test.test_llinterp import interpret
except ImportError:
    pytestmark = py.test.mark.skip("Needs RPython to be on the PYTHONPATH")

[asottile]

I don't think this is different than the advice for the other py library removal -- if they want the entrypoint back they can install py (since they were erroneously depending on it being installed to begin with) -- though they should just change to pytest

[nicoddemus]

good point

[nicoddemus]

To complement:

@frenzymadness those libraries use the py library but they do not explicitly have py listed in their dependencies, relying on the fact that pytest itself depended on py until 7.2. This is not a good practice, as libraries should explicitly list all the dependencies that they use directly, and not rely on transitive dependencies from other packages.

There are two possible fixes to be done on those libraries:

1. Change usages from py.test to pytest (recommended).
2. Add py explicitly to their dependencies.

Closing for now, feel free to follow up with other questions.

(Pinning this issue too).

[frenzymadness]

I understand that this is technically not a problem in pytest but py provided some functionality for pytest which is now gone when py is not installed. I also completely understand that it's mostly a problem with the dependencies of the mentioned libraries. But in the end, there is no transition period for codebases still importing py.test.

[asottile]

option 2 is an infinite transition period -- the py.test module was never provided by pytest

[RonnyPfannschmidt]

i would say we are happy to merge a pr that adds a reasonable deprecation trigger for using py.test (which should return the pytest module an trigger a warning )

[asottile]

if we're going to do that we should bring back py.xml and such too (we should not do that)

[RonnyPfannschmidt]

@asottile im not proposing to copy all of pylib, im just proposing that the only alias that we can provide without copying legacy code should be something we accept as external contribution

[asottile]

I don't think we should accept that either

[RonnyPfannschmidt]

i can understand the sentiment

[frenzymadness]

I understand your point of view. Moreover, I'm thinking about it and I don't see a possible solution that would not require reintroducing the dependency on py and raising the warning from there, unfortunately.