[pytest-dev] the sorry state of pylib tests and pylib
me at the-compiler.org
Tue Sep 27 12:07:56 EDT 2016
* 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,
I also really can't find anything significant with a few GitHub
> 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 ;)
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...
Size: 801 bytes
Desc: not available
More information about the pytest-dev