[pytest-dev] the sorry state of pylib tests and pylib

[Ronny Pfannschmidt]

On 27.09.2016 16:25, Bruno Oliveira wrote:
>
>
> On Tue, Sep 27, 2016 at 11:14 AM Ronny Pfannschmidt
> <opensource at ronnypfannschmidt.de
> <mailto:opensource at ronnypfannschmidt.de>> wrote:
>
>
>
>     On 27.09.2016 15:59, Bruno Oliveira wrote:
>>     On Tue, Sep 27, 2016 at 10:07 AM Ronny Pfannschmidt
>>     <opensource at ronnypfannschmidt.de
>>     <mailto:opensource at ronnypfannschmidt.de>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20160927/b4c433bc/attachment.html>