[pytest-dev] pytest 3.1 warning capture woes

[Bruno Oliveira]

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 <nicoddemus at gmail.com> 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 <
> opensource at ronnypfannschmidt.de> 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 <flub at devork.be> wrote:
>>
>>> Hi,
>>>
>>> On 26 May 2017 at 15:51, Brian Okken <variedthoughts at gmail.com> 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 listpytest-dev at python.orghttps://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170529/45c77972/attachment.html>