* Bruno Oliveira <[email protected]> [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 <[email protected]> [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 | [email protected] (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
signature.asc
Description: PGP signature
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
