On 27.09.2016 16:25, Bruno Oliveira wrote: > > > On Tue, Sep 27, 2016 at 11:14 AM Ronny Pfannschmidt > <[email protected] > <mailto:[email protected]>> wrote: > > > > On 27.09.2016 15:59, Bruno Oliveira wrote: >> On Tue, Sep 27, 2016 at 10:07 AM Ronny Pfannschmidt >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> as things stand we have to maintain it until py.test no >> longer depends on it >> >> a 2.0 release that kills py.code is a non-option as any >> project dependign on ot will be limited in py.test version >> >> >> Don't we already vendor py.code in pytest? That makes it >> independent from what's installed on the system, at least as far >> as py.code is concerned. My idea was just to remove parts which >> py.test does not use or is vendored in (svn and py.code come to >> mind). >> > we vendored it to since changing its api in pylib would break > down-streams > if we now remove it we break down-streams just the same > > > 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. > > and we could just have put it into a separate package to begin with > > > One of the reasons to vendor it was to make it easier to fix bugs on > it without having to apply the fix in a separate library and make a > separate release; just moving py.code to a separate package would not > help with that. > well, the fact that we need more than 5 minutes to do a release is concerning - i#d prefer if we could handle that differently but well, vendoring py.code destroyed most tests for py.code in pylib, and we cant yet abandon pylib
by now i think it would be much more easy to separate py.code and and prepare to either freeze or evolve it > >> 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 > > >> About py.path, we could implement a backward compatible interface >> which is implemented as a thin layer in terms of pathlib (I think >> we discussed this on GTalk some other day). > thats one of the plans > but i would like to eventually get rid of the api alltogether, > we couldnt push it when we had the chance, and now pathlib is the > standard > > > 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. > > Cheers, > Bruno.
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
