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 <[email protected]>: >* 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/ _______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
