Consider moving the bits we need to pytest's codebase?

[nicoddemus]

We should consider moving the bits we still use from py into the pytest codebase. The experience we had moving py.code to pytest was a positive one (IMHO), so perhaps we should follow up with other bits we use as well? A quick list:

• py.path.common.
• py.io (some bits only);
• py.xml (this can be replaced by the builtin etree btw).

By moving those bits to pytest we can focus on maintaining the bits that are of interest to us (pytest maintainers) and drop the py dependency altogether.

[The-Compiler]

Do you mean py.path.local? I think when moving it into pytest, we can also easily start to deprecate things which are probably not commonly used, and which we couldn't easily expose when writing a py.path compatibility layer over the stdlib pathlib. I'm thinking things like .pypkgpath() / .pyimport() / .sysexec() etc.

[nicoddemus]

Do you mean py.path.local?

Yes, thanks.

[RonnyPfannschmidt]

we cant move py.path because we would severely break the api, and im fairly certain no matter what we do we break the world

i'd much rather start to expose path-lib paths everywhere and leave the deprecated py.path attributes in there a backward shim

at some point we can go as far as having a declarative approach to that that allows opt out of having py.path availiable (the error can just tell to install it when using the deprecated mechanism)

since we didn't even manage to clean up py.code, i am highly critical of moving pylib bits into pytest as we dont demonstrate the necessary followup

for py.io, we really should make a new pypi package, pytest shouldnt start to turn into a dump of libraries in internal folders that we then sluggishly maintain

also we should take a look at getting tid of things like terminalwriter, its api is problematic

py.xml should be killed

[nicoddemus]

we cant move py.path because we would severely break the api, and im fairly certain no matter what we do we break the world

Indeed I had the same thought after I posted this. People are instantiating py.path.local and comparing pytest's path objects against that class in current code, and copying py.path to pytest will result in a different class which will break lots of code.

i'd much rather start to expose path-lib paths everywhere and leave the deprecated py.path attributes in there a backward shim

We should detail that proposal in pytest; I don't see how we can do it cleanly because we will have to "invent" new names for existing attributes, for example item.fspath; having a different name will add to the confusion I believe. (Not that I have a better proposal, mind you).

since we didn't even manage to clean up py.code

I wasn't aware we still needed work on pytest regarding py.code. What is still needed?

for py.io, we really should make a new pypi package, pytest shouldnt start to turn into a dump of libraries in internal folders that we then sluggishly maintain

Not sure what you mean by "sluggishly maintain"; but if we plan to deprecate/get rid of something, we shouldn't make a separate package to give the impression that it will be maintained and should be used. IMO it makes much more sense to move that as an internal implementation detail which we can get rid in the future when convenient for us.

py.xml should be killed

You mean you should stop using it in pytest? Definitely, there is a perfectly valid alternative in the stdlib, etree.

Just to remember, our py.code move premise was to easier our maintenance and stop doing maintenance of py.code (in py); we never planned to actually remove it from py because this might break existing code needlessly. This is the same reason why you don't remove packages from PyPI even if they are no longer maintained. If people are using and it is working for them, that's good, but we won't spend any time maintaining it so they can fork or create a new library if they want to carry it on.

[RonnyPfannschmidt]

wrt new names for paths, i tried a different solution before and it completely failed (see the previous pr wrt pathlib2

we should expose a pytest.Path, which is either pathlib2 or pathlib , and then start to introduce new attributes while deprecating old ones

wrt py.code currenelty py.code exception info handling is a total mess and absolutely entangled with terminalwriter apis, thats a death sentence for the pytest internals and their sane boundaries

in addition the py.code.source stuff is a deadweight with bugs we should get rid off

and then there are the missing features we direly need (like framework sectioning of trace-backs, built-in serialization of trace-backs)

so far all we did was move it over and fix a few small issues we should fix in pylib anyway (from my pov thats a failure and extra cost)

and also what i mean by sluggish maintaining,

[bluetech]

I think the discussion here is mostly outdated (pytest now only uses py.path.local and we track the progress on that on the pytest repo), so closing.