Hi everyone, Ronny and I discussed a bit on GTalk and realized that perhaps we can fix the current warnings plugin and avoid having to disable it entirely: simply removing the filter installed in https://github.com/pytest-dev/pytest/blob/master/_pytest/warnings.py#L56 might be sufficient to fix the affected suites. Installing that filter unfortunately overrides all custom filters because it will take priority over everything else. I did a quick test with the example posted in https://github.com/pytest-dev/pytest/issues/2430 and it does work.
New proposal: create a PR with the fix above and test it in a few of the suites mentioned in https://github.com/pytest-dev/pytest/issues/2430. If this actually fixes it, we can make a 3.1.1 release which is now just a simple bug fix. We did discover however that this will *not* show deprecation warnings by default though. To make them appear, we need to install a custom filter but we are not sure which filter to install at the moment. Thoughts? Bruno. On Mon, May 29, 2017 at 9:20 AM Bruno Oliveira <[email protected]> wrote: > Thanks everyone. > > If it is alright then, I will prepare a 3.2.0 release later today. > > Cheers, > Bruno. > > On Mon, May 29, 2017 at 9:18 AM RonnyPfannschmidt < > [email protected]> wrote: > >> *resent after bad email client config* >> i like the 3.2 plan, >> >> i think its fine to mark 3.1 as botched >> >> we should have a proper discussion about feature lifetimes in future, >> just deprecation is simply not enough - and it seems we repeat mishaps >> around releasing "complete" features >> -- Ronny >> >> Am 29.05.2017 um 14:06 schrieb Bruno Oliveira: >> >> Hi Floris and Brian, thanks for joining. >> >> On Mon, May 29, 2017 at 8:44 AM Floris Bruynooghe <[email protected]> wrote: >> >>> Hi, >>> >>> On 26 May 2017 at 15:51, Brian Okken <[email protected]> wrote: >>> > My opinion: >>> > - make 3.1.1 with this feature opt in >>> >>> I'd have agreed with this initially. But I think releasing an >>> un-broken version should probably only be done within the first >>> 24-48h. After that the pain might just increase rather then decrease. >>> >> >> If we were to make it opt-in, I would rather release a 3.2.0 version; >> this way we can think of 3.1 as a "botched" release and more emphatically >> communicate the change to users. >> >> > - new features that change behavior in backwards incompatible way >>> should be >>> > opt in. >>> >>> Probably with a note that next major release they'll be switched on by >>> default and give people the time to already disable them in their >>> config for that case >>> >> >> Sounds like a good idea. The problem in this case was that we didn't >> foresee stuff actually breaking, otherwise it would be an opt-in feature >> from the start. >> >> Guys, anymore opinions? I'm willing to prepare a 3.2.0 release today with >> warnings opt-in if we all agree this is the best course of action. >> >> Cheers, >> Bruno. >> >> >> _______________________________________________ >> pytest-dev mailing >> [email protected]https://mail.python.org/mailman/listinfo/pytest-dev >> >>
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
