On Tue, Sep 27, 2016 at 11:14 AM Ronny Pfannschmidt < [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]> 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. 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. > 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
