[meta] Replace pylib with other constructs

[obestwalter]

NOTE to make the transition easier, I suggest waiting until we can drop 2.6 support (when pip 10 is released) - see milestone status.

pylib is not actively maintained anymore (last release was end of 2014) and we should slowly move to actively maintained constructs and remove constructs that trip up static code analysis in modern IDEs.

• py.std.[stdlib module]

instead of accessing stdlib modules through this shortcut they should be used as intended (normal import)

see: #592

• py.builtin

This is used as a py2/py3 comaptibility layer, so these should be replaced wiht use of e.g. six

• py.path

Should be replaced with e.g. stdlib pathlib (there is a Python2 backport)

• py.io

TODO

• py.process

TODO

Each part should be addressed in a separate PR.

[nicoddemus]

py.path
Should be replaced with e.g. stdlib pathlib (there is a Python2 backport)

I'm interested in ideas on how to do this in particular; it is hard because py.path is part of public APIs in many places in pytest, and quite a few in tox as well.

[obestwalter]

Hi @nicoddemus tox has no public API except for its hooks.

tox/CHANGELOG

Lines 55 to 56 in 0af5700

	- rename internal files -- tox offers no external API except for the
	experimental plugin hooks, use tox internals at your own risk.

[obestwalter]

No concrete ideas yet how to tackle that. But my gut feeling is that this will be part of a world breaking tox 3.0 :)

[nicoddemus]

Good point, for tox I think the problem is much smaller given only a few hooks and plugins might depend on it. For pytest is quite the contrary thought... 😓

[obestwalter]

Yeah, I feel you. I mean there is even the tmpdir fixture that provides a py.path object, so that gets officially exposed. I usually have a fixture in my conftest to override that with the current path object of my choice. Maybe in pytest the ship has sailed and we're at least stuck with the py.path API for a very long time?

[The-Compiler]

I remember having talked with some people about this (at the sprint last year maybe?) and the plan was to have a layer over pathlib which exposes an API similar (or ideally the same to) py.path, with a config option to turn that compatibility layer off.

[RonnyPfannschmidt]

@The-Compiler i believe that was for pytest

[nicoddemus]

@The-Compiler yep we talked about this, but the lingering aspect of this was: how solid can we make that compatibility layer, and how long it would last. Unlike other parts of deprecated code, py.path is very central to a lot of things in pytest, starting from tmpdir which is an extremely used fixture, to a lot of hooks which deal with important objects having py.path objects as public API (config.rootdir for example).

[nicoddemus]

@RonnyPfannschmidt made me realize we might be hijacking this thread, so we probably should move this discussion over to pytest-dev/pytest#2230. 😬

[obestwalter]

I think it's not going to be that horrible for tox, but we'll cross that bridge once we get there (not this year anymore, I am pretty sure).

[gaborbernat]

Let's do this with tox 4 and python 3 only.

[jayvdb]

I am guessing that the work is effectively already completed as part of #1394 , and there is no desire to fix this in tox v3.. ?

I'd be willing to attempt at least a minimal pathlib fix for tox v3 if there is maintainer interest in this, as I am running into py.path complications on other PRs I am working on.

Might be worth adding a note about that at the top of the issue, or even close this issue.

[gaborbernat]

That's the hope. However, we'll keep the issue open until v4 is out.

[gaborbernat]

With the release of version 4 alpha this now has been resolved.