Pytest: Please remove the dependency on 'py'

[mgorny]

Since 'py' isn't really receiving any attention, and distributions end up carrying growing pile of patches just to keep it working, I think it'd be reasonable for pytest to stop requiring it. Just to be clear, right now we need to patch tests to work with pytest-4+, we hackaround breakages in python3.8 and python3.9 is around the corner with yet another set of problems.

[RonnyPfannschmidt]

We are working on it, it's still going to take years

[bluetech]

In master, we are down to depending on only two parts of py: py.path.local and py.iniconfig (and one instance of py.error.Error which I can remove). Migrating from py.path.local would require a big effort, but py.iniconfig can be imported quite easily. WDYT @RonnyPfannschmidt?

[RonnyPfannschmidt]

Ini config is already externalized, no need to copy into pytest

[kerizane]

Is the plan documented anyway? Any preferences or guidelines?

[RonnyPfannschmidt]

the plan is not documented anywhere, in detail yet, we created https://github.com/pytest-dev/pytest/projects/4 to de-tangle and track it

[Zac-HD]

Personally I'd be happy to have a hard-cutover to pathlib in pytest 6.0

It's a significant change and may be a breaking one for some users and plugins, but I think likely to cause less churn in dependencies than trying to invent a compatibility layer. I estimate that almost no end-users will be directly affected, and only a small fraction of plugins - and importantly that it will be easier on pytest maintainers to help plugins migrate than to have an upstream compat layer.

[nicoddemus]

It's a significant change and may be a breaking one for some users and plugins

Oh no it would break the world: tmpdir (a very used fixture) is a py.path.local object.

[Zac-HD]

Ah. Yes, that would do it :man_facepalming:

[RonnyPfannschmidt]

Personally i will reject a compatibility layer beyond casting some objects to local paths and leaving behind the legacy properties which do

Support for py.path.local will then be constrained to the python versions where pylib works and pylib will turn into a optional dependency that's declared dead

[bluetech]

In master, we are down to depending on only two parts of py: py.path.local and py.iniconfig

For some reason, one slipped my mind: py.xml used in the junitxml plugin.

[nicoddemus]

Oh right. That will be a simple, but arduous refactoring.

[kerizane]

junitxml already has a ticket:
https://github.com/pytest-dev/pytest/issues/4970

[gnikonorov]

Question. What is the reason for py’s existence? Were the features it added just not available in standard python at the time or was it optimized for pytest?

[nicoddemus]

The first one: it dates before/around Python 3.0 was released, so it contained a bunch of utilities that worked in both Python 2 and Python 3.0 at the time, plus general utilities such as xml manipulation, file first-class objects, I/O, and including py.test, which was the early stages of pytest. pytest was in fact born by extracting py.test from py.

Since then, there are better alternatives for all of which is implemented there, that's why we have no interest in adding new features to it, or even maintaining it if possible.

[gnikonorov]

Thank you for the explanation @nicoddemus