[pytest-dev] the sorry state of pylib tests and pylib

[Ronny Pfannschmidt]

Various distros debundle already, at least apipkg is severely outdated and a mess
-- Ronny

Am 27. September 2016 18:07:56 MESZ, schrieb Florian Bruhin <me at the-compiler.org>:
>* Bruno Oliveira <nicoddemus at gmail.com> [2016-09-27 14:25:43 +0000]:
>> Yes, but those downstream projects would have the option o pinning to
>pylib
>> < 2. Plus I think there must be almost no projects using it, it seems
>very
>> pytest specific, that was one of the reasonings we used to justify
>> vendoring py.code into pytest in the first place.
>
>At least in Debian, only pytest and some pytest-plugins have a reverse
>dependency on it:
>
>pytest, pytest-cov, pytest-django, pytest-instafail, pytest-pylint,
>pytest-xdist
>
>I also really can't find anything significant with a few GitHub
>searches either.
>
>> Sure, but removing that API is a very long term plan IMHO because
>tons of
>> code depend on it (tmpdir is certainly a very popular fixture) so I
>> wouldn't dare remove it in the next few years.
>> 
>> We could eventually introduce a separate fixture which provides the
>pathlib
>> interface, and eventually move tmpdir to a separate plugin for legacy
>code
>> to use. But this would be very down the road in my opinion.
>
>I think the plan we discussed somewhere (here? At the sprint?) is
>having a compat layer over pathlib (with the things nobody hopefully
>uses, like the svn stuff removed), and then having a configuration
>option people could switch to have normal pathlib.Path objects
>instead. I know it's something I'd do in my testsuite! ;)
>
>* Ronny Pfannschmidt <opensource at ronnypfannschmidt.de> [2016-09-27
>16:32:10 +0200]:
>> but well, vendoring py.code  destroyed most tests for py.code in
>pylib,
>> and we cant yet abandon pylib
>
>If we don't find any non-pytest project using it, why not?
>
>> >>         my plan is to de-vendor bits of pylib (like iniconfig,
>apipkg)
>> >>
>> >>     You mean remove them from pylib and publish them as isolated
>> >>     packages? 
>> >>
>> >     correct, the main reason to pull in things like iniconfig and
>> >     apipkg was, bad packaging tooling 6-7 years ago
>> >     its much better now
>> >
>> >
>> > I see, but that would break downstream projects which use those
>> > sub-packages as well, right? Note that I'm fine to do that in a 2.0
>> > release.
>> pylib can just expose them the same way it exposes py.test,
>> the main problem is stable api
>
>FWIW it also generates some overhead for downstream distribution
>packagers if every distribution suddenly needs to package a handful of
>new dependencies for everything ;)
>
>Florian
>
>-- 
>http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>         I love long mails! | http://email.is-not-s.ms/