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

[Florian Bruhin]

* 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20160927/89afb069/attachment.sig>