On Tue, Sep 27, 2016 at 18:07 +0200, Florian Bruhin wrote: > * 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
do you mean that in debian no packages depend on py? What about tox to begin with? > I also really can't find anything significant with a few GitHub > searches either. and FWIW github searches shows a lot of hits for py.path.local() at least: https://github.com/search?utf8=%E2%9C%93&q=%22py.path.local%22++extension%3Apy&type=Code&ref=searchresults or do you really mean just "py.code"? holger > > 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 _______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
