From nicoddemus at gmail.com  Thu May  4 08:43:35 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 04 May 2017 12:43:35 +0000
Subject: [pytest-dev] Remove AUTHORS file?
Message-ID: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>

Hi everyone,

I was wondering what people thought about removing the AUTHORS file from
pytest and point to GH's Contributors link instead?

https://github.com/pytest-dev/pytest/graphs/contributors

This is automatically generated from the commits to the repository, so
there's no maintenance involved.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170504/62b26b1f/attachment.html>

From nicoddemus at gmail.com  Thu May  4 09:46:21 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 04 May 2017 13:46:21 +0000
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
In-Reply-To: <CAAWk_DyGS0wvSNiOt5_=SusVhO5LrkNy0AXEHfYRkukGaVpNzw@mail.gmail.com>
References: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
 <CAAWk_DyGS0wvSNiOt5_=SusVhO5LrkNy0AXEHfYRkukGaVpNzw@mail.gmail.com>
Message-ID: <CA+RQFfdrTVZLQfsE8_-Rh4fbe6YTXxs0gy8hqEY6_rMOf6NRBQ@mail.gmail.com>

For reference: https://github.com/pytest-dev/pytest/issues/2390

On Tue, Mar 28, 2017 at 3:45 AM Floris Bruynooghe <flub at devork.be> wrote:

> This gets a big +1 from me, it would be great to have this done more
> easily.
>
> On 21 Mar 2017 8:54 a.m., "Ronny Pfannschmidt" <
> opensource at ronnypfannschmidt.de> wrote:
>
>> Hi all,
>>
>> today i noticed how pip manages its change-logs in a pretty interesting
>> way,
>>
>> they manage the fragments to be composed before a release in the folder
>> "news" in files named like "$ticketnumber.$changetype"
>> before a release those files get take out and composed into the
>> change-log.
>>
>> The fabulous tool behind that is https://github.com/hawkowl/towncrier/ -
>> after taking a first look at it,
>> i believe it should be a massive enhancement compared to what we put
>> ourselves trough right now.
>>
>> i also would be delighted, if we used it in more projects ^^
>>
>> cheers,
>>
>> Ronny
>>
>>
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170504/698958d3/attachment.html>

From flub at devork.be  Thu May  4 10:07:31 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 04 May 2017 16:07:31 +0200
Subject: [pytest-dev] Remove AUTHORS file?
In-Reply-To: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>
References: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>
Message-ID: <87wp9waf6k.fsf@powell.devork.be>

Bruno Oliveira <nicoddemus at gmail.com> writes:

> Hi everyone,
>
> I was wondering what people thought about removing the AUTHORS file from
> pytest and point to GH's Contributors link instead?
>
> https://github.com/pytest-dev/pytest/graphs/contributors
>
> This is automatically generated from the commits to the repository, so
> there's no maintenance involved.

What's nice is that AUTHORS is just an alphabetical list of people while
the github page ranks people implicitly by some random metric.  It's
also possible for packagers to install this file, currently Debian does
that for CPython's ACKS file but not for pytest's AUTHORS so who knows
how valuable that is.  I don't care overly strong though, I'd vote -0.

Cheers,
Floris

From nicoddemus at gmail.com  Thu May  4 10:24:36 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 04 May 2017 14:24:36 +0000
Subject: [pytest-dev] Remove AUTHORS file?
In-Reply-To: <87wp9waf6k.fsf@powell.devork.be>
References: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>
 <87wp9waf6k.fsf@powell.devork.be>
Message-ID: <CA+RQFfcayhft7GuFAWFORE8daKWJwQ9cdQuXj=uFt-M5M_Dkig@mail.gmail.com>

On Thu, May 4, 2017 at 11:07 AM Floris Bruynooghe <flub at devork.be> wrote:

> What's nice is that AUTHORS is just an alphabetical list of people while
> the github page ranks people implicitly by some random metric.  It's
> also possible for packagers to install this file, currently Debian does
> that for CPython's ACKS file but not for pytest's AUTHORS so who knows
> how valuable that is.  I don't care overly strong though, I'd vote -0.
>

All good points, thanks Floris.

In light of that, I propose to change it so it is generated automatically
from git, would that be acceptable?

I'm considering introducing Invoke tasks so we have a well known set of
tasks that automate that kind of stuff, for example:

$ invoke generate_authors
$ invoke generate_news
$ invoke generate_announce

And so on.

Eventually we can get to the point where all the changes needed for a
release can be done with two commands:

$ git tag 3.1.0
$ invoke prepare_release nicoddemus

Where 'prepare_release' would generate news, authors, package and upload a
devpi package to nicoddemus/dev on devpi.

Cheers,
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170504/1e59eab3/attachment.html>

From flub at devork.be  Thu May  4 11:10:20 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 04 May 2017 17:10:20 +0200
Subject: [pytest-dev] Remove AUTHORS file?
In-Reply-To: <CA+RQFfcayhft7GuFAWFORE8daKWJwQ9cdQuXj=uFt-M5M_Dkig@mail.gmail.com>
References: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>
 <87wp9waf6k.fsf@powell.devork.be>
 <CA+RQFfcayhft7GuFAWFORE8daKWJwQ9cdQuXj=uFt-M5M_Dkig@mail.gmail.com>
Message-ID: <87o9v8ac9v.fsf@powell.devork.be>

Bruno Oliveira <nicoddemus at gmail.com> writes:

> On Thu, May 4, 2017 at 11:07 AM Floris Bruynooghe <flub at devork.be> wrote:
>
>> What's nice is that AUTHORS is just an alphabetical list of people while
>> the github page ranks people implicitly by some random metric.  It's
>> also possible for packagers to install this file, currently Debian does
>> that for CPython's ACKS file but not for pytest's AUTHORS so who knows
>> how valuable that is.  I don't care overly strong though, I'd vote -0.
>>
>
> All good points, thanks Floris.
>
> In light of that, I propose to change it so it is generated automatically
> from git, would that be acceptable?
>
> I'm considering introducing Invoke tasks so we have a well known set of
> tasks that automate that kind of stuff, for example:
>
> $ invoke generate_authors
> $ invoke generate_news
> $ invoke generate_announce
>
> And so on.
>
> Eventually we can get to the point where all the changes needed for a
> release can be done with two commands:
>
> $ git tag 3.1.0
> $ invoke prepare_release nicoddemus
>
> Where 'prepare_release' would generate news, authors, package and upload a
> devpi package to nicoddemus/dev on devpi.

That all sounds great!

From me at the-compiler.org  Thu May  4 13:40:52 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 4 May 2017 19:40:52 +0200
Subject: [pytest-dev] Remove AUTHORS file?
In-Reply-To: <CA+RQFfcayhft7GuFAWFORE8daKWJwQ9cdQuXj=uFt-M5M_Dkig@mail.gmail.com>
References: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>
 <87wp9waf6k.fsf@powell.devork.be>
 <CA+RQFfcayhft7GuFAWFORE8daKWJwQ9cdQuXj=uFt-M5M_Dkig@mail.gmail.com>
Message-ID: <20170504174052.od4d7dmn55hf6qp2@hooch.localdomain>

On Thu, May 04, 2017 at 02:24:36PM +0000, Bruno Oliveira wrote:
> On Thu, May 4, 2017 at 11:07 AM Floris Bruynooghe <flub at devork.be> wrote:
> 
> > What's nice is that AUTHORS is just an alphabetical list of people while
> > the github page ranks people implicitly by some random metric.  It's
> > also possible for packagers to install this file, currently Debian does
> > that for CPython's ACKS file but not for pytest's AUTHORS so who knows
> > how valuable that is.  I don't care overly strong though, I'd vote -0.
> >
> 
> All good points, thanks Floris.
> 
> In light of that, I propose to change it so it is generated automatically
> from git, would that be acceptable?

FWIW here's what I do for qutebrowser:
https://github.com/qutebrowser/qutebrowser/blob/v0.10.1/scripts/dev/src2asciidoc.py#L425-L445

I have a small dict of author name corrections for people who
(accidentally) use different names in their commits. I also order people
by the number of commits, which might or might not be a good idea.

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
         I love long mails!  | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170504/6981df77/attachment.sig>

From nicoddemus at gmail.com  Thu May  4 13:47:10 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 04 May 2017 17:47:10 +0000
Subject: [pytest-dev] Remove AUTHORS file?
In-Reply-To: <20170504174052.od4d7dmn55hf6qp2@hooch.localdomain>
References: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>
 <87wp9waf6k.fsf@powell.devork.be>
 <CA+RQFfcayhft7GuFAWFORE8daKWJwQ9cdQuXj=uFt-M5M_Dkig@mail.gmail.com>
 <20170504174052.od4d7dmn55hf6qp2@hooch.localdomain>
Message-ID: <CA+RQFfehCr-qHmELg_0df62zhpY=ZgowbRDxn4o-AJzQg730tg@mail.gmail.com>

On Thu, May 4, 2017 at 2:42 PM Florian Bruhin <me at the-compiler.org> wrote:

> On Thu, May 04, 2017 at 02:24:36PM +0000, Bruno Oliveira wrote:
> > In light of that, I propose to change it so it is generated automatically
> > from git, would that be acceptable?
>
> FWIW here's what I do for qutebrowser:
>
> https://github.com/qutebrowser/qutebrowser/blob/v0.10.1/scripts/dev/src2asciidoc.py#L425-L445


Thanks for the link Florian, the corrections dict is a good idea.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170504/99e336ab/attachment.html>

From nicoddemus at gmail.com  Wed May 10 14:13:26 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 10 May 2017 18:13:26 +0000
Subject: [pytest-dev] Remove AUTHORS file?
In-Reply-To: <CA+RQFfehCr-qHmELg_0df62zhpY=ZgowbRDxn4o-AJzQg730tg@mail.gmail.com>
References: <CA+RQFfd3coduL1YEVu4BsGTsWJbp_53tREpjpS0ng9rbV2VVcw@mail.gmail.com>
 <87wp9waf6k.fsf@powell.devork.be>
 <CA+RQFfcayhft7GuFAWFORE8daKWJwQ9cdQuXj=uFt-M5M_Dkig@mail.gmail.com>
 <20170504174052.od4d7dmn55hf6qp2@hooch.localdomain>
 <CA+RQFfehCr-qHmELg_0df62zhpY=ZgowbRDxn4o-AJzQg730tg@mail.gmail.com>
Message-ID: <CA+RQFff3Hh6RBJr8BRGXkDQ=9tAMrQ3LkzWJymE-PduxRt-==g@mail.gmail.com>

Hi everyone,

On Thu, May 4, 2017 at 2:47 PM Bruno Oliveira <nicoddemus at gmail.com> wrote:

> On Thu, May 4, 2017 at 2:42 PM Florian Bruhin <me at the-compiler.org> wrote:
>
>> On Thu, May 04, 2017 at 02:24:36PM +0000, Bruno Oliveira wrote:
>> > In light of that, I propose to change it so it is generated
>> automatically
>> > from git, would that be acceptable?
>>
>> FWIW here's what I do for qutebrowser:
>>
>> https://github.com/qutebrowser/qutebrowser/blob/v0.10.1/scripts/dev/src2asciidoc.py#L425-L445
>
>
> Thanks for the link Florian, the corrections dict is a good idea.
>

For those interested in this topic, I've opened a PR introducing a task to
generate update the announcement docs when making a new release:

https://github.com/pytest-dev/pytest/pull/2397

I've decided to drop the idea of a task to generate the AUTHORS file from
the git history, it seems too much work for little gain. Copying from the
PR above:

---

I started with a task to generate the AUTHORS file from git history but
because pytest has a very old history, a lot of the names (60+) are not in
a proper "name" format, a few examples:

famousgarkin
fijal
foxx
gabriel.reis
getxsick

I realized that finding the proper names would be a ton of work and not
really worth the trouble, given that the AUTHORS file is updated during PRs
and not during the release process.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170510/c38c1d12/attachment.html>

From oliver at bestwalter.de  Fri May 12 15:32:55 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Fri, 12 May 2017 19:32:55 +0000
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <F1502588-1DE5-4A82-B8C1-A61818F9FF71@mozilla.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
 <49073EAC-F76E-4CB1-9FBC-DC5DC8E5E93D@mozilla.com>
 <CAG5Cgtr3+57Ob5nVQBBR5AWcfWdw4ZBR=T7TqUNMpm_jXXO0KQ@mail.gmail.com>
 <F1502588-1DE5-4A82-B8C1-A61818F9FF71@mozilla.com>
Message-ID: <CAG5CgtpDN=nES8ri0U1rK03LTYBjz_UQPRu71Gn=pyTjuZVq-w@mail.gmail.com>

Hi all,

I just got a mail that the helpdesk proposal was accepted. The date is not
scheduled yet. Will keep you posted.

Cheers,
Oliver

On Mon, 24 Apr 2017 at 17:03 Dave Hunt <dhunt at mozilla.com> wrote:

> Unfortunately not. Might be able to attend a pytest sprint if one is
> planned, but otherwise it?ll probably be next year for me.
>
>
> On 24 Apr 2017, at 16:00, Oliver Bestwalter <oliver at bestwalter.de> wrote:
>
> Hi Dave,
>
> no problem - was looking forward to see you to though. Are you attending
> Pycon US? I might be there for the sprints.
>
> Cheers,
> Oliver
>
> On Mon, 24 Apr 2017 at 15:56 Dave Hunt <dhunt at mozilla.com> wrote:
>
>> Unfortunately I?ve decided not to attend EuroPython this year, so I?ll
>> need to revoke my offer to help out. Hopefully next year..!
>>
>> On 28 Mar 2017, at 09:21, Dave Hunt <dhunt at mozilla.com> wrote:
>>
>> I?m thinking of coming to EuroPython, and would be happy to spend some
>> time at the helpdesk. My particular area of expertise would be the plugins
>> I maintain, but I?m sure I can also answer some pytest/tox/devpi queries
>> too.
>>
>> Cheers,
>> Dave
>>
>> On 27 Mar 2017, at 21:42, Oliver Bestwalter <oliver at bestwalter.de> wrote:
>>
>> Hi all,
>>
>> EuroPython is on the horizon and they have a new thing (or at least new
>> for me) called "helpdesk"
>>
>> > Helpdesk / 10 slots
>>
>> > Helpdesks are a great way to share your experience on a technology, by
>> offering to help people answering their questions and solving their
>> practical problems. You can run a helpdesk by yourself or with colleagues
>> and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
>> the morning and 1.5 hours in the afternoon. People looking for help will
>> sign up for a 30 minute slot and talk to you. There is no specific
>> preparation needed; you just need to be proficient in the technology you
>> run the helpdesk for.
>>
>> see: https://ep2017.europython.eu/en/call-for-proposals/
>>
>> I would be interested to try this and volunteer to help with questions
>> about tox mainly. Would anybody else interested in that kind of thing? If
>> we find a handful of people that would want to do that, we could have a
>> tox/pytest/devpi helpdesk :)
>>
>> Cheers,
>> Oliver
>> _______________________________________________
>> tox-dev mailing list
>> tox-dev at python.org
>> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170512/68f783f9/attachment.html>

From opensource at ronnypfannschmidt.de  Fri May 12 17:56:32 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 12 May 2017 23:56:32 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
Message-ID: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>

Hi everyone,

with the recent discovery of 
https://github.com/pytest-dev/pytest/issues/2398 which was a result of 
accidentally introducing object as base class in pytest-2.9.1 via 
https://github.com/pytest-dev/pytest/pull/1486

since https://github.com/pytest-dev/pytest/pull/2179 , which will go 
into pytest-3.1 does the "same"
i propose considering this as breaking change (since there are subtle 
differences on the python 2 side after all)

while doing that we can also gracefully resolve the regression by 
documenting the earlier accidental change and the new expectations.

-- Ronny


From opensource at ronnypfannschmidt.de  Tue May 16 09:52:12 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Tue, 16 May 2017 15:52:12 +0200
Subject: [pytest-dev] moving execnet over to gh under pytest-dev
Message-ID: <0c44de02-5719-1170-b1b3-8da1a8eb0ca9@ronnypfannschmidt.de>

Hi,

i'd like to move execnet under pytest-dev on github,

the author-map was completed a while ago, all that's missing is to move
the history and converting the issues.

i'm asking of there are any objections,
else i'll tackle it later this week.


-- Ronny


From nicoddemus at gmail.com  Tue May 16 09:57:49 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 16 May 2017 13:57:49 +0000
Subject: [pytest-dev] moving execnet over to gh under pytest-dev
In-Reply-To: <0c44de02-5719-1170-b1b3-8da1a8eb0ca9@ronnypfannschmidt.de>
References: <0c44de02-5719-1170-b1b3-8da1a8eb0ca9@ronnypfannschmidt.de>
Message-ID: <CA+RQFffwx_buAvgWRO2B4W=gbEoE_4dyV79Y6nTYKiaPe2E-vg@mail.gmail.com>

On Tue, May 16, 2017 at 10:56 AM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi,
>
> i'd like to move execnet under pytest-dev on github,
>
>
+1, definitely. Thanks Ronny!

[]s,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170516/4124c659/attachment.html>

From nicoddemus at gmail.com  Tue May 16 15:13:24 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 16 May 2017 19:13:24 +0000
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
Message-ID: <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>

Hi everyone,

On Fri, May 12, 2017 at 7:03 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> with the recent discovery of
> https://github.com/pytest-dev/pytest/issues/2398 which was a result of
> accidentally introducing object as base class in pytest-2.9.1 via
> https://github.com/pytest-dev/pytest/pull/1486
>
> since https://github.com/pytest-dev/pytest/pull/2179 , which will go
> into pytest-3.1 does the "same"
> i propose considering this as breaking change (since there are subtle
> differences on the python 2 side after all)
>
> while doing that we can also gracefully resolve the regression by
> documenting the earlier accidental change and the new expectations.
>

Any thoughts on this proposal? I would like to release the new version this
week if possible, so it would be nice to get this discussion going. :)

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170516/866b9eb1/attachment.html>

From me at the-compiler.org  Tue May 16 15:37:01 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 16 May 2017 21:37:01 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
Message-ID: <20170516193701.popczfiicscadpcd@hooch.localdomain>

On Tue, May 16, 2017 at 07:13:24PM +0000, Bruno Oliveira wrote:
> Hi everyone,
> 
> On Fri, May 12, 2017 at 7:03 PM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
> 
> > with the recent discovery of
> > https://github.com/pytest-dev/pytest/issues/2398 which was a result of
> > accidentally introducing object as base class in pytest-2.9.1 via
> > https://github.com/pytest-dev/pytest/pull/1486
> >
> > since https://github.com/pytest-dev/pytest/pull/2179 , which will go
> > into pytest-3.1 does the "same"
> > i propose considering this as breaking change (since there are subtle
> > differences on the python 2 side after all)
> >
> > while doing that we can also gracefully resolve the regression by
> > documenting the earlier accidental change and the new expectations.
> >
> 
> Any thoughts on this proposal? I would like to release the new version this
> week if possible, so it would be nice to get this discussion going. :)

No strong feelings from my side. I can kind of see both "we should
follow semver, so this should be 4.0", and "if this is called 4.0,
people might hesitate to upgrade even if it doesn't affect them".

That being said, after having a pytest 2.7 and 3.x, it'd be nice to
finally resolve the confusion between pytest and python's version
numbering :D

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
         I love long mails!  | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170516/0c1104fa/attachment.sig>

From variedthoughts at gmail.com  Tue May 16 15:31:24 2017
From: variedthoughts at gmail.com (Brian Okken)
Date: Tue, 16 May 2017 12:31:24 -0700
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
Message-ID: <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>

I don't get the "broke the API" part of this issue. 
What used to work and doesn't now?
Is this really significant enough to warrant bumping to 4.0. 
Are you ready to follow through with the deprecating promise of  https://docs.pytest.org/en/latest/backwards-compatibility.html so soon after the introduction of 3.0?

How many people are affected by this change compared to the confusion of having to explain to everyone what the major feature(s) of 4.0 is(are)?

- Brian 




Sent from my iPhone
> On May 16, 2017, at 12:13 PM, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> 
> Hi everyone,
> 
>> On Fri, May 12, 2017 at 7:03 PM Ronny Pfannschmidt <opensource at ronnypfannschmidt.de> wrote:
>> with the recent discovery of
>> https://github.com/pytest-dev/pytest/issues/2398 which was a result of
>> accidentally introducing object as base class in pytest-2.9.1 via
>> https://github.com/pytest-dev/pytest/pull/1486
>> 
>> since https://github.com/pytest-dev/pytest/pull/2179 , which will go
>> into pytest-3.1 does the "same"
>> i propose considering this as breaking change (since there are subtle
>> differences on the python 2 side after all)
>> 
>> while doing that we can also gracefully resolve the regression by
>> documenting the earlier accidental change and the new expectations.
>  
> Any thoughts on this proposal? I would like to release the new version this week if possible, so it would be nice to get this discussion going. :)
> 
> Cheers,
> Bruno.
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170516/741eade6/attachment.html>

From nicoddemus at gmail.com  Wed May 17 13:01:34 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 17 May 2017 17:01:34 +0000
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
Message-ID: <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>

On Tue, May 16, 2017 at 4:31 PM Brian Okken <variedthoughts at gmail.com>
wrote:

> I don't get the "broke the API" part of this issue.
> What used to work and doesn't now?
>

We changed all classes to new-style classes in order to remove the subtle
differences between old style and new style, which may affect Python 2
users.

One example of such difference is that "x[0]" will raise a TypeError if x
is a new-style class, and AttributeError if it is an old style class.
Here's an real world code that broke because of this (
https://github.com/ManageIQ/integration_tests/pull/4645/files):

     if hasattr(report, 'skipped'):
          if report.skipped:
              try:
                  contents = report.longrepr[2]
              except AttributeError:
                  contents = str(report.longrepr)

Btw, the change for this particular incompatibility was released in 3.0.5
mostly by accident, where TerminalRepr was changed to subclass from object
in
https://github.com/pytest-dev/pytest/commit/fbc5ba08d969adafd71ecb6fce25a1cad76bb983
.

Issue https://github.com/pytest-dev/pytest/issues/2398 contains more
detailed info.


Is this really significant enough to warrant bumping to 4.0.
>
Are you ready to follow through with the deprecating promise of
> https://docs.pytest.org/en/latest/backwards-compatibility.html so soon
> after the introduction of 3.0?
>
> How many people are affected by this change compared to the confusion of
> having to explain to everyone what the major feature(s) of 4.0 is(are)?
>

I believe that the purpose of this thread is to exactly discuss if this
accidental change is enough to warrant a 4.0 release.

I'm also under the impression that this will affect very few users, but
would like to hear opinions from everyone. That accidental change from old
to new-style went out in 3.0.5, if it was a major breaking point we would
have heard more reports about it for now (although the current features
branch changed *all* classes to new-style).

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170517/1200ef1d/attachment.html>

From holger at merlinux.eu  Wed May 17 13:08:26 2017
From: holger at merlinux.eu (holger krekel)
Date: Wed, 17 May 2017 19:08:26 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
Message-ID: <20170517170826.q5yijmjkummatih2@merlinux.eu>

On Wed, May 17, 2017 at 17:01 +0000, Bruno Oliveira wrote:
> On Tue, May 16, 2017 at 4:31 PM Brian Okken <variedthoughts at gmail.com>
> wrote:
> 
> > I don't get the "broke the API" part of this issue.
> > What used to work and doesn't now?
> >
> 
> We changed all classes to new-style classes in order to remove the subtle
> differences between old style and new style, which may affect Python 2
> users.
> 
> One example of such difference is that "x[0]" will raise a TypeError if x
> is a new-style class, and AttributeError if it is an old style class.
> Here's an real world code that broke because of this (
> https://github.com/ManageIQ/integration_tests/pull/4645/files):
> 
>      if hasattr(report, 'skipped'):
>           if report.skipped:
>               try:
>                   contents = report.longrepr[2]
>               except AttributeError:
>                   contents = str(report.longrepr)
> 
> Btw, the change for this particular incompatibility was released in 3.0.5
> mostly by accident, where TerminalRepr was changed to subclass from object
> in
> https://github.com/pytest-dev/pytest/commit/fbc5ba08d969adafd71ecb6fce25a1cad76bb983
> .
> 
> Issue https://github.com/pytest-dev/pytest/issues/2398 contains more
> detailed info.
> 
> 
> Is this really significant enough to warrant bumping to 4.0.
> >
> Are you ready to follow through with the deprecating promise of
> > https://docs.pytest.org/en/latest/backwards-compatibility.html so soon
> > after the introduction of 3.0?
> >
> > How many people are affected by this change compared to the confusion of
> > having to explain to everyone what the major feature(s) of 4.0 is(are)?
> >
> 
> I believe that the purpose of this thread is to exactly discuss if this
> accidental change is enough to warrant a 4.0 release.
> 
> I'm also under the impression that this will affect very few users, but
> would like to hear opinions from everyone. That accidental change from old
> to new-style went out in 3.0.5, if it was a major breaking point we would
> have heard more reports about it for now (although the current features
> branch changed *all* classes to new-style).

FWIW i also think it makes sense to consider increasing a major version number by making an educated guess (like you do) on how many people it is likely to affect.   

holger

From flub at devork.be  Wed May 17 13:18:28 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 17 May 2017 18:18:28 +0100
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
Message-ID: <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>

Hi,

We have a deprecation cycle so we can't just break the API and bump to
4.0 as I understand it.  So we accidentally broke the API, that sucks
but generally I don't think we can fix that anymore because rolling it
back will break it again for those who already adjusted.  However
given the deprecation cycle I think the only real option we have is to
rollback all the other changes to subclass object as we know that will
break more API instead of releasing that change.  This means things
will stay the same for python 2 users and python 3 users.  Eventually
we won't need it anyway as python 2 gets dropped (wishful thinking, I
know!), so we never have to do this painful transition explicitly.

Cheers,
Floris


On 17 May 2017 at 18:01, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> On Tue, May 16, 2017 at 4:31 PM Brian Okken <variedthoughts at gmail.com>
> wrote:
>>
>> I don't get the "broke the API" part of this issue.
>> What used to work and doesn't now?
>
>
> We changed all classes to new-style classes in order to remove the subtle
> differences between old style and new style, which may affect Python 2
> users.
>
> One example of such difference is that "x[0]" will raise a TypeError if x is
> a new-style class, and AttributeError if it is an old style class. Here's an
> real world code that broke because of this
> (https://github.com/ManageIQ/integration_tests/pull/4645/files):
>
>      if hasattr(report, 'skipped'):
>           if report.skipped:
>               try:
>                   contents = report.longrepr[2]
>               except AttributeError:
>                   contents = str(report.longrepr)
>
> Btw, the change for this particular incompatibility was released in 3.0.5
> mostly by accident, where TerminalRepr was changed to subclass from object
> in
> https://github.com/pytest-dev/pytest/commit/fbc5ba08d969adafd71ecb6fce25a1cad76bb983.
>
> Issue https://github.com/pytest-dev/pytest/issues/2398 contains more
> detailed info.
>
>
>> Is this really significant enough to warrant bumping to 4.0.
>>
>> Are you ready to follow through with the deprecating promise of
>> https://docs.pytest.org/en/latest/backwards-compatibility.html so soon after
>> the introduction of 3.0?
>>
>> How many people are affected by this change compared to the confusion of
>> having to explain to everyone what the major feature(s) of 4.0 is(are)?
>
>
> I believe that the purpose of this thread is to exactly discuss if this
> accidental change is enough to warrant a 4.0 release.
>
> I'm also under the impression that this will affect very few users, but
> would like to hear opinions from everyone. That accidental change from old
> to new-style went out in 3.0.5, if it was a major breaking point we would
> have heard more reports about it for now (although the current features
> branch changed *all* classes to new-style).
>
> Cheers,
> Bruno.
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>

From flub at devork.be  Wed May 17 13:19:37 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 17 May 2017 18:19:37 +0100
Subject: [pytest-dev] moving execnet over to gh under pytest-dev
In-Reply-To: <0c44de02-5719-1170-b1b3-8da1a8eb0ca9@ronnypfannschmidt.de>
References: <0c44de02-5719-1170-b1b3-8da1a8eb0ca9@ronnypfannschmidt.de>
Message-ID: <CAAWk_DwYLV3eZ0p=H668svGZY6Yca1Yz_LiCroqT0RX=28RZNA@mail.gmail.com>

On 16 May 2017 at 14:52, Ronny Pfannschmidt
<opensource at ronnypfannschmidt.de> wrote:
> Hi,
>
> i'd like to move execnet under pytest-dev on github,

no objections from me.

From opensource at ronnypfannschmidt.de  Wed May 17 16:35:52 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 17 May 2017 22:35:52 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
Message-ID: <8888D470-8627-4DB7-8F77-BDDF9148AA4D@ronnypfannschmidt.de>

Personally ID strongly prefer a major release because we do change an api that is consumed,

IMHO we should do one on any case where we know beforehand,

But as we don't implement strict semver,
I opened this discussion to generate a consensus.

My general impression is that the majority  agrees on a minor release being sufficient, and I can go with that.

-- Ronny

Am 17. Mai 2017 19:01:34 MESZ schrieb Bruno Oliveira <nicoddemus at gmail.com>:
>On Tue, May 16, 2017 at 4:31 PM Brian Okken <variedthoughts at gmail.com>
>wrote:
>
>> I don't get the "broke the API" part of this issue.
>> What used to work and doesn't now?
>>
>
>We changed all classes to new-style classes in order to remove the
>subtle
>differences between old style and new style, which may affect Python 2
>users.
>
>One example of such difference is that "x[0]" will raise a TypeError if
>x
>is a new-style class, and AttributeError if it is an old style class.
>Here's an real world code that broke because of this (
>https://github.com/ManageIQ/integration_tests/pull/4645/files):
>
>     if hasattr(report, 'skipped'):
>          if report.skipped:
>              try:
>                  contents = report.longrepr[2]
>              except AttributeError:
>                  contents = str(report.longrepr)
>
>Btw, the change for this particular incompatibility was released in
>3.0.5
>mostly by accident, where TerminalRepr was changed to subclass from
>object
>in
>https://github.com/pytest-dev/pytest/commit/fbc5ba08d969adafd71ecb6fce25a1cad76bb983
>.
>
>Issue https://github.com/pytest-dev/pytest/issues/2398 contains more
>detailed info.
>
>
>Is this really significant enough to warrant bumping to 4.0.
>>
>Are you ready to follow through with the deprecating promise of
>> https://docs.pytest.org/en/latest/backwards-compatibility.html so
>soon
>> after the introduction of 3.0?
>>
>> How many people are affected by this change compared to the confusion
>of
>> having to explain to everyone what the major feature(s) of 4.0
>is(are)?
>>
>
>I believe that the purpose of this thread is to exactly discuss if this
>accidental change is enough to warrant a 4.0 release.
>
>I'm also under the impression that this will affect very few users, but
>would like to hear opinions from everyone. That accidental change from
>old
>to new-style went out in 3.0.5, if it was a major breaking point we
>would
>have heard more reports about it for now (although the current features
>branch changed *all* classes to new-style).
>
>Cheers,
>Bruno.

-- 
Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170517/9fc61a48/attachment.html>

From nicoddemus at gmail.com  Wed May 17 17:27:09 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 17 May 2017 21:27:09 +0000
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
Message-ID: <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>

On Wed, May 17, 2017 at 2:18 PM Floris Bruynooghe <flub at devork.be> wrote:

> We have a deprecation cycle so we can't just break the API and bump to
> 4.0 as I understand it.  So we accidentally broke the API, that sucks
> but generally I don't think we can fix that anymore


That's true, we won't help anybody by bumping the version to 4.0 because
that particular change (TerminalRepr being updated to new-style class) has
already been in effect since 2016-12-05.

given the deprecation cycle I think the only real option we have is to
> rollback all the other changes to subclass object as we know that will
> break more API instead of releasing that change.
>

That's a very good point.

On Wed, May 17, 2017 at 5:35 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Personally ID strongly prefer a major release because we do change an api
> that is consumed,
>

You are right, but as Floris commented fortunately we can still rollback
that change.

IMHO we should do one on any case where we know beforehand,
>

Definitely.

My general impression is that the majority agrees on a minor release being
> sufficient, and I can go with that.
>

Given all the points here I think we should rollback the PR which changed
all classes to new-style classes, given that it might generate more
breakages, and go for a 3.1 release.

The TerminalRepr change that went with 3.0.5 will remain as it is, as
rolling back that at this point will generate more confusion.

I've opened a PR reverting the new-style classes change:

https://github.com/pytest-dev/pytest/pull/2414

Unless somebody has other points for discussion, I believe once we merge
that PR we can go for the 3.1 release, what do you guys think?

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170517/1179ef1a/attachment.html>

From me at the-compiler.org  Thu May 18 03:03:21 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 18 May 2017 09:03:21 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
Message-ID: <20170518070321.qx4npmgideqgk4c2@hooch.localdomain>

On Wed, May 17, 2017 at 09:27:09PM +0000, Bruno Oliveira wrote:
> Unless somebody has other points for discussion, I believe once we merge
> that PR we can go for the 3.1 release, what do you guys think?

Go for it! :)

I gave it a try with qutebrowser, and other than pytest-warnings
breaking[1] (which isn't needed anymore anyways), things seem to work
fine.

[1] https://github.com/fschulze/pytest-warnings/issues/9

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
         I love long mails!  | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170518/47172d08/attachment.sig>

From nicoddemus at gmail.com  Thu May 18 07:38:30 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 18 May 2017 11:38:30 +0000
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
Message-ID: <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>

On Thu, May 18, 2017 at 1:13 AM Ronny Pfannschmidt <ich at ronnypfannchmidt.de>
wrote:

> I'd prefer if we do not undo the change.
>

Do you mean the change to the TerminalRepr in 3.0.5, or the complete PR
which changes all classes to new style classes?

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170518/f79b0467/attachment-0001.html>

From nicoddemus at gmail.com  Thu May 18 08:56:19 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 18 May 2017 12:56:19 +0000
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
 <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>
 <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
Message-ID: <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>

On Thu, May 18, 2017 at 9:47 AM Ronny Pfannschmidt <ich at ronnypfannschmidt.de>
wrote:

> that pr that changes all classes, i'd like to keep it, just communicate
> the changes correctly
>

Floris, Florian, Holger, are you guys OK with that? I'm fine either way.

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170518/0a241241/attachment.html>

From holger at merlinux.eu  Thu May 18 09:37:50 2017
From: holger at merlinux.eu (holger krekel)
Date: Thu, 18 May 2017 15:37:50 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
 <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>
 <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
 <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
Message-ID: <20170518133750.ab3drvqfjo7g4xch@merlinux.eu>

On Thu, May 18, 2017 at 12:56 +0000, Bruno Oliveira wrote:
> On Thu, May 18, 2017 at 9:47 AM Ronny Pfannschmidt <ich at ronnypfannschmidt.de>
> wrote:
> 
> > that pr that changes all classes, i'd like to keep it, just communicate
> > the changes correctly
> >
> 
> Floris, Florian, Holger, are you guys OK with that? I'm fine either way.

To be honest, i never was a fan to change to object baseclassing wholesale -- 
i prefer do it in relation to features/bugs work on a case by case basis.

So I am very slightly in favor of just avoiding potential fallout here -- it does not make maintenance harder (IMO) -- and if it does in some particular case we can change that case then.   It's "very slightly" because i don't think doing it wholesale would break too many things, either.

holger

From flub at devork.be  Thu May 18 13:25:51 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Thu, 18 May 2017 18:25:51 +0100
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
 <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>
 <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
 <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
Message-ID: <CAAWk_Dx_8jX+izGGb4=xTx5W1n+nYKP7kVn+n_vyvtE3dwsWLA@mail.gmail.com>

On 18 May 2017 at 13:56, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>
>
> On Thu, May 18, 2017 at 9:47 AM Ronny Pfannschmidt
> <ich at ronnypfannschmidt.de> wrote:
>>
>> that pr that changes all classes, i'd like to keep it, just communicate
>> the changes correctly
>
>
> Floris, Florian, Holger, are you guys OK with that? I'm fine either way.

Personally I don't object the change either, though I agree with
Holger's thoughts on doing something like this and being conservative
often pays off, but sure it is more annoying.

My main objection was purely on the fact that we basically disobey the
deprecation policy right after introducing it by doing this.  If we do
go with Ronny's approach of just bumping the version number when
breaking backwards compat (which is what setuptools and pip and the
like do afaik) then we really should update that policy to reflect so.
I just thought the reason the policy was introduced was because of
user feedback on our earlier behaviour where we usually randomly
justified breakages because it made development more convenient.

From nicoddemus at gmail.com  Thu May 18 16:05:31 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 18 May 2017 20:05:31 +0000
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CAAWk_Dx_8jX+izGGb4=xTx5W1n+nYKP7kVn+n_vyvtE3dwsWLA@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
 <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>
 <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
 <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
 <CAAWk_Dx_8jX+izGGb4=xTx5W1n+nYKP7kVn+n_vyvtE3dwsWLA@mail.gmail.com>
Message-ID: <CA+RQFfchCnfu3JK0E3=J3aq85ka2tRu_d3FrgqL_Gd6hSEHk8A@mail.gmail.com>

On Thu, May 18, 2017 at 2:25 PM Floris Bruynooghe <flub at devork.be> wrote:

>
> My main objection was purely on the fact that we basically disobey the
> deprecation policy right after introducing it by doing this.


Hmm you are right, I think this is the central point: introducing this
change is known to possibly break things, so we should obey our deprecation
policy of at least two minor versions before introducing such a change, so
it can't get out in the next release regardless if it it is 4.0 or 3.1.

If we do
> go with Ronny's approach of just bumping the version number when
> breaking backwards compat (which is what setuptools and pip and the
> like do afaik) then we really should update that policy to reflect so.
> I just thought the reason the policy was introduced was because of
> user feedback on our earlier behaviour where we usually randomly
> justified breakages because it made development more convenient.
>

To be fair, this change was introduced not because it makes development
easier, but because of a user's request (
https://github.com/pytest-dev/pytest/issues/2147): the subtle differences
between old style and new style classes can be annoying.

Given all we've discussed so far, I think the change in the end is not
worth the hassle and the possibility of breaking the API further. My
proposal:

1. Drop the new-style class changes (merge #2414).
2. Close the original user request (
https://github.com/pytest-dev/pytest/issues/2147) as "won't fix", detailing
the reasons as we discussed here.
3. Release 3.1. \o/

What do you guys say? Ronny?

Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170518/621fa57a/attachment.html>

From opensource at ronnypfannschmidt.de  Fri May 19 15:57:09 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 19 May 2017 21:57:09 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <CA+RQFfchCnfu3JK0E3=J3aq85ka2tRu_d3FrgqL_Gd6hSEHk8A@mail.gmail.com>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
 <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>
 <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
 <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
 <CAAWk_Dx_8jX+izGGb4=xTx5W1n+nYKP7kVn+n_vyvtE3dwsWLA@mail.gmail.com>
 <CA+RQFfchCnfu3JK0E3=J3aq85ka2tRu_d3FrgqL_Gd6hSEHk8A@mail.gmail.com>
Message-ID: <c3505457-fa1d-b050-f86b-b4e7f3cdaf62@ronnypfannschmidt.de>

(sending again due to prior sender typo)

given the rightfully reasserted constraints that seems a reasonable
course of action,

i'd prefer to keep it reopened instead of won't fix,
and i'd like to see a revising of the deprecation policy,

since as things as
https://github.com/pytest-dev/pytest/labels/mark-issue are impossible to
fix without being able to break things in a sensible way (its just too
much of a mess)

-- Ronny
Am 18.05.2017 um 22:05 schrieb Bruno Oliveira:
>
>
> On Thu, May 18, 2017 at 2:25 PM Floris Bruynooghe <flub at devork.be
> <mailto:flub at devork.be>> wrote:
>
>
>     My main objection was purely on the fact that we basically disobey the
>     deprecation policy right after introducing it by doing this. 
>
>
> Hmm you are right, I think this is the central point: introducing this
> change is known to possibly break things, so we should obey our
> deprecation policy of at least two minor versions before introducing
> such a change, so it can't get out in the next release regardless if
> it it is 4.0 or 3.1.
>
>     If we do
>     go with Ronny's approach of just bumping the version number when
>     breaking backwards compat (which is what setuptools and pip and the
>     like do afaik) then we really should update that policy to reflect so.
>     I just thought the reason the policy was introduced was because of
>     user feedback on our earlier behaviour where we usually randomly
>     justified breakages because it made development more convenient.
>
>
> To be fair, this change was introduced not because it makes
> development easier, but because of a user's request
> (https://github.com/pytest-dev/pytest/issues/2147): the subtle
> differences between old style and new style classes can be annoying.
>
> Given all we've discussed so far, I think the change in the end is not
> worth the hassle and the possibility of breaking the API further. My
> proposal:
>
> 1. Drop the new-style class changes (merge #2414).
> 2. Close the original user request
> (https://github.com/pytest-dev/pytest/issues/2147) as "won't fix",
> detailing the reasons as we discussed here.
> 3. Release 3.1. \o/
>
> What do you guys say? Ronny?
>
> Cheers,
>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

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

From flub at devork.be  Sun May 21 07:27:54 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Sun, 21 May 2017 13:27:54 +0200
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <c3505457-fa1d-b050-f86b-b4e7f3cdaf62@ronnypfannschmidt.de>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
 <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>
 <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
 <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
 <CAAWk_Dx_8jX+izGGb4=xTx5W1n+nYKP7kVn+n_vyvtE3dwsWLA@mail.gmail.com>
 <CA+RQFfchCnfu3JK0E3=J3aq85ka2tRu_d3FrgqL_Gd6hSEHk8A@mail.gmail.com>
 <c3505457-fa1d-b050-f86b-b4e7f3cdaf62@ronnypfannschmidt.de>
Message-ID: <87mva6qwjp.fsf@powell.devork.be>

Ronny Pfannschmidt <opensource at ronnypfannschmidt.de> writes:
> given the rightfully reasserted constraints that seems a reasonable
> course of action,
>
> i'd prefer to keep it reopened instead of won't fix,
> and i'd like to see a revising of the deprecation policy,

What we can do according to our policy is saying in our documentation
and announcements: in two releases time we'll break this backwards
compatibility thing (whether that's new-style classes or marks).  Then
two releases later bump the major version and do it.  It slows breakage
a little bit down and I thought that was the reason for the current
deprecation policy.  Yes it is more annoying as we basically have to
leave a pull-request or branch lying around for all that time and deal
with the merging breakage resulting from this.

Having said that, I'm happy to re-evaluate the policy if enough people
think this is a bad idea.  But I'd like some user feedback as well
before changing it.


Floris

From oliver at bestwalter.de  Sun May 21 08:31:54 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Sun, 21 May 2017 12:31:54 +0000
Subject: [pytest-dev] the potential need to release 4.0 instead of 3.1,
 proposal
In-Reply-To: <87mva6qwjp.fsf@powell.devork.be>
References: <d0cda873-2c0b-5b88-fea5-3096483124a9@ronnypfannschmidt.de>
 <CA+RQFfdBDKfA4R4_p7mb0RCxiR2HLrSEQ4cEAQG3GMd75YBGKA@mail.gmail.com>
 <28A504E1-C92E-47DA-B5AF-BF9DA5A8BD37@gmail.com>
 <CA+RQFfcumh4VeY1yhX14aWY-VBgHfxQ+nMJnqBDYEg4GV05LKw@mail.gmail.com>
 <CAAWk_Dw6U3QEriqNVnAtZqByK3M0jGi+_BxEbZdzEnn7CH-nRg@mail.gmail.com>
 <CA+RQFfeoHs=6vjkvz0g9SeBwfufMEQL0BaY+KNXYmfz2MbeAKQ@mail.gmail.com>
 <79BBB208-85F3-4A11-BADC-66F9EB76F26A@ronnypfannchmidt.de>
 <CA+RQFfdC3TcOyz43V4VcL1tk998MhcmSzrTUoipYbmvO_Mv8eg@mail.gmail.com>
 <ea7761a5-2e61-a5a2-928a-8815a17830a2@ronnypfannschmidt.de>
 <CA+RQFfcQNmrELLBmsZomEHEPdsz2YjW7KBJxdoM1oLF6Zea9vA@mail.gmail.com>
 <CAAWk_Dx_8jX+izGGb4=xTx5W1n+nYKP7kVn+n_vyvtE3dwsWLA@mail.gmail.com>
 <CA+RQFfchCnfu3JK0E3=J3aq85ka2tRu_d3FrgqL_Gd6hSEHk8A@mail.gmail.com>
 <c3505457-fa1d-b050-f86b-b4e7f3cdaf62@ronnypfannschmidt.de>
 <87mva6qwjp.fsf@powell.devork.be>
Message-ID: <CAG5CgtrhhsW-1kpAV_uNMWy-tJHPtdF=sp_dXUvAh55XwqjZYQ@mail.gmail.com>

Hi all,

this is a bit meta, as I have not enough insight about the topic at hand (I
did not follow the discussion closely), but as the one who proposed the
policy at the last sprint, I feel obliged to give my two cents about that
aspect of the discussion. I also try to give my perspective as a pytest
user.

At the last sprint I tried to find a solution to a problem that I
repeatedly noticed during conversations at last years' sprint. There were a
lot of corners in the code where things should be tidied up but can't,
because of backwards compatibility concerns. I wanted to start a discussion
how to be able to break backwards compatibility in an acceptable way for
users, by giving them (on by default) deprecation warnings and having a
clear exit strategy. What I did not want is to introduce unnecessary
friction into the development process. So if it turns out that this is the
case and breaking backwards compatibility is better handled on a case by
case basis in pytest, just revoke the policy and declare it a failed
experiment. No harm done. If it is thought that the policy as basically not
a bad thing but needs tweaking, please let's do that, I am happy to help.

As a user of testing tools like pytest, tox, devpi, coverage, flexmock and
whatnot, I personally do not mind if my CI dependencies break now and then
anyway. If I come into the office in the morning and our CI monitor is an
ocean of red nightly builds, I know that a dependency has broken and I can
deal with it accordingly (e.g. pinning the version until I have adapted my
code or the dependency has been fixed). I think that is just a normal
aspect of being part of a vibrant ecosystem.

Also: maybe some internal changes that break backwards compatibility in a
way that you can't even give proper warnings (like it seems to be the case
with this change ... I am not sure though as I did not understand the
change properly). Then the policy doesn't really apply and it has to be
handled differently (a foolish consistency is the hobgoblin of little minds
after all). The users should then be informed why this happens the way it
does (and why a longer lead up and a major release is not justified
although some backwards compatibility might break). This would still be
perfectly o.k. for me as user. We all sometimes make promises, we can't
keep after all ...

As an aside: here is what happened with the last requests release and how
they handled it: https://github.com/kennethreitz/requests/issues/4006).

Last word from a happy FLOSS user: what always outweighs the pain of broken
things for me is my gratitude towards all the voluntary work that flows
into the libraries and tools that I can use in my daily life instead of
being stuck with prorietary cr***. It's not like somebody dies because my
testing framework broke my CI builds, so I always try to keep things in
perspective :)

Cheers,
Oliver

On Sun, 21 May 2017 at 13:28 Floris Bruynooghe <flub at devork.be> wrote:

> Ronny Pfannschmidt <opensource at ronnypfannschmidt.de> writes:
> > given the rightfully reasserted constraints that seems a reasonable
> > course of action,
> >
> > i'd prefer to keep it reopened instead of won't fix,
> > and i'd like to see a revising of the deprecation policy,
>
> What we can do according to our policy is saying in our documentation
> and announcements: in two releases time we'll break this backwards
> compatibility thing (whether that's new-style classes or marks).  Then
> two releases later bump the major version and do it.  It slows breakage
> a little bit down and I thought that was the reason for the current
> deprecation policy.  Yes it is more annoying as we basically have to
> leave a pull-request or branch lying around for all that time and deal
> with the merging breakage resulting from this.
>
> Having said that, I'm happy to re-evaluate the policy if enough people
> think this is a bad idea.  But I'd like some user feedback as well
> before changing it.
>
>
> Floris
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170521/41a4f4ab/attachment.html>

From me at the-compiler.org  Sun May 21 11:24:22 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 21 May 2017 17:24:22 +0200
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <CA+RQFfc_9fxQ56KzoY=16dE2OCBkYqjkiTK5p2xx=_jZUfdqPQ@mail.gmail.com>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
 <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
 <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>
 <84363a70-f3b1-f2af-c7d4-83a1e6cae350@ronnypfannschmidt.de>
 <CA+RQFfc_9fxQ56KzoY=16dE2OCBkYqjkiTK5p2xx=_jZUfdqPQ@mail.gmail.com>
Message-ID: <20170521152422.ipnea6hf5vemz7vz@hooch.localdomain>

On Wed, Apr 19, 2017 at 11:42:29AM +0000, Bruno Oliveira wrote:
> On Mon, Apr 17, 2017 at 3:49 PM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
> 
> >
> > On 14.04.2017 14:17, Florian Bruhin wrote:
> > > On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote:
> > >> What if we instead of considering features, we released a new minor
> > version
> > >> periodically, for say every month or two? We could adopt the same for
> > bug
> > >> fix releases, like each two weeks.
> > > FWIW what GitLab[1] does is a monthly feature release, and patch
> > > releases whenever needed. I don't think it's a good idea to have a fixed
> > > release cycle for patches, but it sounds like it could work quite well
> > > for feature releases indeed.
> >
> 
> I'm curious, why do you think it is not a good idea to have a fixed or
> semi-fixed release cycle for patches?

Sorry for the late answer, somehow that mail made itself comfortable in
my inbox for a while ;)

I just think it doesn't scale well. If we do something which breaks a
lot of testsuites we don't want to wait with doing a patch release - and
at the same time if we just have some doc fix or even a change which
isn't user-facing at all, doing a release just causes unnecessary work.
Even if we automated our part, releases always mean work for downstreams
like distributions or users with pinned dependencies.

Because of that, I think it makes more sense to be a bit more flexible
with patch releases.

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
         I love long mails!  | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170521/370b8c02/attachment.sig>

From dan.nealschneider at gmail.com  Sun May 21 19:22:57 2017
From: dan.nealschneider at gmail.com (Dan Nealschneider)
Date: Sun, 21 May 2017 16:22:57 -0700
Subject: [pytest-dev] Is anyone at PyCon2017 in Portland?
Message-ID: <CAA9fXhxmpZHovagc4LTmQeuc9MMCUwWkkGxaVk_+VZ4TEt22ig@mail.gmail.com>

Is anyone else at PyCon2017? Are there open issues we could work on during
the Sprints?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170521/2299cb08/attachment.html>

From nicoddemus at gmail.com  Mon May 22 17:57:44 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 22 May 2017 21:57:44 +0000
Subject: [pytest-dev] pytest 3.1.0 has been released!
Message-ID: <CA+RQFfeMjfxbZWQnqDZXTABijxce6MBF3a3yfdtWfVyA1sdVpg@mail.gmail.com>

The pytest team is proud to announce the 3.1.0 release!

pytest is a mature Python testing tool with more than a 1600 tests
against itself, passing on many different interpreters and platforms.

This release contains a number of bugs fixes and improvements, so users are
encouraged
to take a look at the CHANGELOG:

    http://doc.pytest.org/en/latest/changelog.html

For complete documentation, please visit:

    http://docs.pytest.org

As usual, you can upgrade from pypi via:

    pip install -U pytest

Thanks to all who contributed to this release, among them:

* Anthony Sottile
* Ben Lloyd
* Bruno Oliveira
* David Giese
* David Szotten
* Dmitri Pribysh
* Florian Bruhin
* Florian Schulze
* Floris Bruynooghe
* John Towler
* Jonas Obrist
* Katerina Koukiou
* Kodi Arfer
* Krzysztof Szularz
* Lev Maximov
* Lo?c Est?ve
* Luke Murphy
* Manuel Krebber
* Matthew Duck
* Matthias Bussonnier
* Michael Howitz
* Michal Wajszczuk
* Pawe? Adamczak
* Rafael Bertoldi
* Ravi Chandra
* Ronny Pfannschmidt
* Skylar Downes
* Thomas Kriechbaumer
* Vitaly Lashmanov
* Vlad Dragos
* Wheerd
* Xander Johnson
* mandeep
* reut


Happy testing,
The Pytest Development Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170522/d32c73aa/attachment.html>

From opensource at ronnypfannschmidt.de  Tue May 23 08:28:01 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Tue, 23 May 2017 14:28:01 +0200
Subject: [pytest-dev] progressing with fixing mark,
 a potentially backward compatible path to progression
Message-ID: <97fc427d-3dbf-45e7-d205-0a1f35c289b7@ronnypfannschmidt.de>

Hi everyone,

first let me link https://github.com/pytest-dev/pytest/labels/mark-issue
those issues give a basic idea on how badly mark is broken and how it
breaks things for users

(we had some people rewrite their complete testsuites to deal with the
fallout of how bad it is)

a few basic underpinnings already happened in pytest 3.1 with
`pytest.param` and the internal restructuring of marker values

whats missing now is to bring marks onto the collection tree not as a
bastardized broken and inconsistent version of keywords, but as actual
marker objects, without any of the breakages and inconsistencies we see
today

in order to do that i see a need for a new property on all nodes where
the markers of a node are discover-able (get_marker is broken beyond
repair i'm not going to fix that before we can get a correct view of marks)

this property can then be used to pass over marks of the ndoes, the
parent nodes and so on, in order to get a consistent view on markers for
an item

in order to make this work consistently with parameterization,
i will introduce a FunctionDefinition node (and a function-definition
scope), that will upon collection apply the parameters (and invoke the
generate_tests hook (also now we will be able to give metafunc a correct
view of marks)

and then a function node will just be the final parameterized call to a
function definition,

in order to ensure this works nicely,
i will introduce a pytestmark property on all marked functions,
that acts like the attribute property on classes, but will not be
affected by the legacy marker transfer

once we have a basic clean data-set for markers on all nodes we can
begin to fix up apis like get_marker and/or deprecate as we see need

in the next step we can introduce opt-outs of the old and staining
marking mechanim and prepare for a truly breaking release

-- Ronny


From opensource at ronnypfannschmidt.de  Tue May 23 12:18:54 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Tue, 23 May 2017 18:18:54 +0200
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <20170521152422.ipnea6hf5vemz7vz@hooch.localdomain>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
 <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
 <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>
 <84363a70-f3b1-f2af-c7d4-83a1e6cae350@ronnypfannschmidt.de>
 <CA+RQFfc_9fxQ56KzoY=16dE2OCBkYqjkiTK5p2xx=_jZUfdqPQ@mail.gmail.com>
 <20170521152422.ipnea6hf5vemz7vz@hooch.localdomain>
Message-ID: <f9fef78d-e9de-2ef5-4be7-3690c0d5c2cd@ronnypfannschmidt.de>

https://github.com/pytest-dev/pytest/issues/2430 is a perfect example of
why we need *more* and *faster* feedback

we keep doing things like that and i think we should reexamine on how we
want to handle those
i am very disappointed with our current process, the feedback speed is
very sub-par and it shows
i want to see, more and smaller releases so we can get more detailed
feedback

i also want to see smaller and more self-contained changes

i want the time back where, when pytest breaks, the user can fix it
(its what got me to pytest in the first place)

and i don't see it coming back if we keep doing what we currently do

-- Ronny

Am 21.05.2017 um 17:24 schrieb Florian Bruhin:
> On Wed, Apr 19, 2017 at 11:42:29AM +0000, Bruno Oliveira wrote:
>> On Mon, Apr 17, 2017 at 3:49 PM Ronny Pfannschmidt <
>> opensource at ronnypfannschmidt.de> wrote:
>>
>>> On 14.04.2017 14:17, Florian Bruhin wrote:
>>>> On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote:
>>>>> What if we instead of considering features, we released a new minor
>>> version
>>>>> periodically, for say every month or two? We could adopt the same for
>>> bug
>>>>> fix releases, like each two weeks.
>>>> FWIW what GitLab[1] does is a monthly feature release, and patch
>>>> releases whenever needed. I don't think it's a good idea to have a fixed
>>>> release cycle for patches, but it sounds like it could work quite well
>>>> for feature releases indeed.
>> I'm curious, why do you think it is not a good idea to have a fixed or
>> semi-fixed release cycle for patches?
> Sorry for the late answer, somehow that mail made itself comfortable in
> my inbox for a while ;)
>
> I just think it doesn't scale well. If we do something which breaks a
> lot of testsuites we don't want to wait with doing a patch release - and
> at the same time if we just have some doc fix or even a change which
> isn't user-facing at all, doing a release just causes unnecessary work.
> Even if we automated our part, releases always mean work for downstreams
> like distributions or users with pinned dependencies.
>
> Because of that, I think it makes more sense to be a bit more flexible
> with patch releases.
>
> Florian
>
>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

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

From nicoddemus at gmail.com  Tue May 23 13:30:25 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 23 May 2017 17:30:25 +0000
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <f9fef78d-e9de-2ef5-4be7-3690c0d5c2cd@ronnypfannschmidt.de>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
 <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
 <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>
 <84363a70-f3b1-f2af-c7d4-83a1e6cae350@ronnypfannschmidt.de>
 <CA+RQFfc_9fxQ56KzoY=16dE2OCBkYqjkiTK5p2xx=_jZUfdqPQ@mail.gmail.com>
 <20170521152422.ipnea6hf5vemz7vz@hooch.localdomain>
 <f9fef78d-e9de-2ef5-4be7-3690c0d5c2cd@ronnypfannschmidt.de>
Message-ID: <CA+RQFfdmFtMEcYGN=V2aysmH3zoBqGg=Ph4ChM5qShtPVfbdRw@mail.gmail.com>

On Tue, May 23, 2017 at 1:18 PM RonnyPfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> https://github.com/pytest-dev/pytest/issues/2430 is a perfect example of
> why we need *more* and *faster* feedback
>
> we keep doing things like that and i think we should reexamine on how we
> want to handle those
> i am very disappointed with our current process, the feedback speed is
> very sub-par and it shows
> i want to see, more and smaller releases so we can get more detailed
> feedback
>
> i also want to see smaller and more self-contained changes
>
> i want the time back where, when pytest breaks, the user can fix it
> (its what got me to pytest in the first place)
>
> and i don't see it coming back if we keep doing what we currently do
>

I agree we need to make minor releases more often and I was under the
impression that everyone also agreed to that, in fact we are now taking
steps to make the release even simpler. :)

Having a features branch in order to be able to make quick bug fix releases
is independent from making more frequent minor releases, IMHO.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170523/e2b136e1/attachment.html>

From nicoddemus at gmail.com  Thu May 25 20:29:50 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 26 May 2017 00:29:50 +0000
Subject: [pytest-dev] pytest 3.1 warning capture woes
Message-ID: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>

Hi everyone,

Unfortunately pytest's 3.1 warning capture being active by default has
caused grief on some test suites and there's been a lengthy discussion
about it on this thread:

https://github.com/pytest-dev/pytest/issues/2430

I'm pointing this out here so others can join the discussion and share
their thoughts.

Also, I'm wondering what should be our next course of action on this.
Should we make a new release (3.1.1, 3.2, 4.0?) where this feature is
opt-in or if by now it is too late to revert it given that those affected
might have already fixed their suites.

As a lesson learned here I'm starting to think that we should from now on
always introduce new features as opt-in, and if we want to change the
defaults do so only on a major release.

Would love to hear everyone's opinion on this.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170526/05de67b4/attachment.html>

From variedthoughts at gmail.com  Fri May 26 09:51:28 2017
From: variedthoughts at gmail.com (Brian Okken)
Date: Fri, 26 May 2017 06:51:28 -0700
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
Message-ID: <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>

My opinion:
- make 3.1.1 with this feature opt in 
- new features that change behavior in backwards incompatible way should be opt in. 
- once the warnings system works, make it a recommended practice to turn it on. 
- make sure --strict and warnings -> errors works

> On May 25, 2017, at 5:29 PM, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> 
> Hi everyone,
> 
> Unfortunately pytest's 3.1 warning capture being active by default has caused grief on some test suites and there's been a lengthy discussion about it on this thread:
> 
> https://github.com/pytest-dev/pytest/issues/2430
> 
> I'm pointing this out here so others can join the discussion and share their thoughts.
> 
> Also, I'm wondering what should be our next course of action on this. Should we make a new release (3.1.1, 3.2, 4.0?) where this feature is opt-in or if by now it is too late to revert it given that those affected might have already fixed their suites.
> 
> As a lesson learned here I'm starting to think that we should from now on always introduce new features as opt-in, and if we want to change the defaults do so only on a major release.
> 
> Would love to hear everyone's opinion on this.
> 
> Cheers,
> Bruno.
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170526/faaee3c3/attachment.html>

From morten at mortenvp.com  Sat May 27 05:21:45 2017
From: morten at mortenvp.com (Morten V. Pedersen)
Date: Sat, 27 May 2017 11:21:45 +0200
Subject: [pytest-dev] pytest-testdirectory fixture
Message-ID: <c0aa4988-089f-83d4-8e61-f6083ec5f400@mortenvp.com>

Hi all,
Just wanted to share a fixture that we have created for py.test. The 
purpose of the fixture, is to make it easy to create folders and run 
commands. E.g. for integration testing small utilities etc.

https://github.com/steinwurf/pytest-testdirectory

The fixture supports a number of different operations. Hope some of you 
will find it useful.

All the best,
Morten

From flub at devork.be  Mon May 29 02:36:37 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 29 May 2017 08:36:37 +0200
Subject: [pytest-dev] pytest-testdirectory fixture
In-Reply-To: <c0aa4988-089f-83d4-8e61-f6083ec5f400@mortenvp.com>
References: <c0aa4988-089f-83d4-8e61-f6083ec5f400@mortenvp.com>
Message-ID: <87vaokkw3u.fsf@powell.devork.be>

Hi Morten,

That looks nice.  It's a similar idea as what pytest uses internally to
test itself, but without all the messiness there.  Good to finally see a
simple external version of this.  Thanks for publishing it as a plugin!

Regards,
Floris


"Morten V. Pedersen" <morten at mortenvp.com> writes:

> Hi all,
> Just wanted to share a fixture that we have created for py.test. The 
> purpose of the fixture, is to make it easy to create folders and run 
> commands. E.g. for integration testing small utilities etc.
>
> https://github.com/steinwurf/pytest-testdirectory
>
> The fixture supports a number of different operations. Hope some of you 
> will find it useful.
>
> All the best,
> Morten
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From morten at mortenvp.com  Mon May 29 07:27:51 2017
From: morten at mortenvp.com (Morten V. Pedersen)
Date: Mon, 29 May 2017 13:27:51 +0200
Subject: [pytest-dev] pytest-testdirectory fixture
In-Reply-To: <87vaokkw3u.fsf@powell.devork.be>
References: <c0aa4988-089f-83d4-8e61-f6083ec5f400@mortenvp.com>
 <87vaokkw3u.fsf@powell.devork.be>
Message-ID: <8590cd22-f0d6-43bf-18fb-1c55269cb11d@mortenvp.com>

Hi Floris,
Thanks. Did not know that there was an internal similar thing in pytest. 
I take a look at that, perhaps some things can be improved based on the 
ideas there.

All the best,
Morten

On 05/29/2017 08:36 AM, Floris Bruynooghe wrote:
> Hi Morten,
>
> That looks nice.  It's a similar idea as what pytest uses internally to
> test itself, but without all the messiness there.  Good to finally see a
> simple external version of this.  Thanks for publishing it as a plugin!
>
> Regards,
> Floris
>
>
> "Morten V. Pedersen" <morten at mortenvp.com> writes:
>
>> Hi all,
>> Just wanted to share a fixture that we have created for py.test. The
>> purpose of the fixture, is to make it easy to create folders and run
>> commands. E.g. for integration testing small utilities etc.
>>
>> https://github.com/steinwurf/pytest-testdirectory
>>
>> The fixture supports a number of different operations. Hope some of you
>> will find it useful.
>>
>> All the best,
>> Morten
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev


From flub at devork.be  Mon May 29 07:39:08 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 29 May 2017 13:39:08 +0200
Subject: [pytest-dev] progressing with fixing mark,
 a potentially backward compatible path to progression
In-Reply-To: <97fc427d-3dbf-45e7-d205-0a1f35c289b7@ronnypfannschmidt.de>
References: <97fc427d-3dbf-45e7-d205-0a1f35c289b7@ronnypfannschmidt.de>
Message-ID: <CAAWk_DwrH-vjPuR7JVQ2wD2VnR1Ce2+8VNxZrnVeRqZ4vb=r4g@mail.gmail.com>

Seems like a sane approach at first sight.  What are the risks to
breaking plugins which rely on the collection nodes?  I'm guessing
fairly small as there are just some new intermediate collection nodes.

Thanks for your perseverance in this battle to sort out marks!

Floris

On 23 May 2017 at 14:28, RonnyPfannschmidt
<opensource at ronnypfannschmidt.de> wrote:
> Hi everyone,
>
> first let me link https://github.com/pytest-dev/pytest/labels/mark-issue
> those issues give a basic idea on how badly mark is broken and how it
> breaks things for users
>
> (we had some people rewrite their complete testsuites to deal with the
> fallout of how bad it is)
>
> a few basic underpinnings already happened in pytest 3.1 with
> `pytest.param` and the internal restructuring of marker values
>
> whats missing now is to bring marks onto the collection tree not as a
> bastardized broken and inconsistent version of keywords, but as actual
> marker objects, without any of the breakages and inconsistencies we see
> today
>
> in order to do that i see a need for a new property on all nodes where
> the markers of a node are discover-able (get_marker is broken beyond
> repair i'm not going to fix that before we can get a correct view of marks)
>
> this property can then be used to pass over marks of the ndoes, the
> parent nodes and so on, in order to get a consistent view on markers for
> an item
>
> in order to make this work consistently with parameterization,
> i will introduce a FunctionDefinition node (and a function-definition
> scope), that will upon collection apply the parameters (and invoke the
> generate_tests hook (also now we will be able to give metafunc a correct
> view of marks)
>
> and then a function node will just be the final parameterized call to a
> function definition,
>
> in order to ensure this works nicely,
> i will introduce a pytestmark property on all marked functions,
> that acts like the attribute property on classes, but will not be
> affected by the legacy marker transfer
>
> once we have a basic clean data-set for markers on all nodes we can
> begin to fix up apis like get_marker and/or deprecate as we see need
>
> in the next step we can introduce opt-outs of the old and staining
> marking mechanim and prepare for a truly breaking release
>
> -- Ronny
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From opensource at ronnypfannschmidt.de  Mon May 29 07:41:25 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Mon, 29 May 2017 13:41:25 +0200
Subject: [pytest-dev] progressing with fixing mark,
 a potentially backward compatible path to progression
In-Reply-To: <CAAWk_DwrH-vjPuR7JVQ2wD2VnR1Ce2+8VNxZrnVeRqZ4vb=r4g@mail.gmail.com>
References: <97fc427d-3dbf-45e7-d205-0a1f35c289b7@ronnypfannschmidt.de>
 <CAAWk_DwrH-vjPuR7JVQ2wD2VnR1Ce2+8VNxZrnVeRqZ4vb=r4g@mail.gmail.com>
Message-ID: <e8ecac2b-131f-01f4-42d7-9a68cff1f23f@ronnypfannschmidt.de>

i don't even want to guess the risk,
the related code feels like the kind of spaghetti that happens after
composite materials polymerize

^^

-- Ronny

Am 29.05.2017 um 13:39 schrieb Floris Bruynooghe:
> Seems like a sane approach at first sight.  What are the risks to
> breaking plugins which rely on the collection nodes?  I'm guessing
> fairly small as there are just some new intermediate collection nodes.
> 
> Thanks for your perseverance in this battle to sort out marks!
> 
> Floris
> 
> On 23 May 2017 at 14:28, RonnyPfannschmidt
> <opensource at ronnypfannschmidt.de> wrote:
>> Hi everyone,
>>
>> first let me link https://github.com/pytest-dev/pytest/labels/mark-issue
>> those issues give a basic idea on how badly mark is broken and how it
>> breaks things for users
>>
>> (we had some people rewrite their complete testsuites to deal with the
>> fallout of how bad it is)
>>
>> a few basic underpinnings already happened in pytest 3.1 with
>> `pytest.param` and the internal restructuring of marker values
>>
>> whats missing now is to bring marks onto the collection tree not as a
>> bastardized broken and inconsistent version of keywords, but as actual
>> marker objects, without any of the breakages and inconsistencies we see
>> today
>>
>> in order to do that i see a need for a new property on all nodes where
>> the markers of a node are discover-able (get_marker is broken beyond
>> repair i'm not going to fix that before we can get a correct view of marks)
>>
>> this property can then be used to pass over marks of the ndoes, the
>> parent nodes and so on, in order to get a consistent view on markers for
>> an item
>>
>> in order to make this work consistently with parameterization,
>> i will introduce a FunctionDefinition node (and a function-definition
>> scope), that will upon collection apply the parameters (and invoke the
>> generate_tests hook (also now we will be able to give metafunc a correct
>> view of marks)
>>
>> and then a function node will just be the final parameterized call to a
>> function definition,
>>
>> in order to ensure this works nicely,
>> i will introduce a pytestmark property on all marked functions,
>> that acts like the attribute property on classes, but will not be
>> affected by the legacy marker transfer
>>
>> once we have a basic clean data-set for markers on all nodes we can
>> begin to fix up apis like get_marker and/or deprecate as we see need
>>
>> in the next step we can introduce opt-outs of the old and staining
>> marking mechanim and prepare for a truly breaking release
>>
>> -- Ronny
>>
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev

From flub at devork.be  Mon May 29 07:44:00 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 29 May 2017 13:44:00 +0200
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
Message-ID: <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>

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.

> - 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

From flub at devork.be  Mon May 29 07:46:35 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 29 May 2017 13:46:35 +0200
Subject: [pytest-dev] pytest-testdirectory fixture
In-Reply-To: <8590cd22-f0d6-43bf-18fb-1c55269cb11d@mortenvp.com>
References: <c0aa4988-089f-83d4-8e61-f6083ec5f400@mortenvp.com>
 <87vaokkw3u.fsf@powell.devork.be>
 <8590cd22-f0d6-43bf-18fb-1c55269cb11d@mortenvp.com>
Message-ID: <CAAWk_DxnvC6vHk8-Jq3kFAL5d3sPiJB8Z0yeSMbnJFWB_JUG-w@mail.gmail.com>

On 29 May 2017 at 13:27, Morten V. Pedersen <morten at mortenvp.com> wrote:
> Hi Floris,
> Thanks. Did not know that there was an internal similar thing in pytest. I
> take a look at that, perhaps some things can be improved based on the ideas
> there.

It's in _pytest/pytester.py if you're looking.  But it really is much
messier then your plugin and too specific to pytest.  Your plugin
looks much nicer for external use.  I'd not be too eager to copy
features of the internal plugin unless one of your users actually
wants them.


Cheers,
Floris

From nicoddemus at gmail.com  Mon May 29 08:06:12 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 29 May 2017 12:06:12 +0000
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
Message-ID: <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170529/efa1fc84/attachment.html>

From opensource at ronnypfannschmidt.de  Mon May 29 08:18:45 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Mon, 29 May 2017 14:18:45 +0200
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
 <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
Message-ID: <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>

*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
> <mailto:flub at devork.be>> wrote:
>
>     Hi,
>
>     On 26 May 2017 at 15:51, Brian Okken <variedthoughts at gmail.com
>     <mailto: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 list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

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

From nicoddemus at gmail.com  Mon May 29 08:20:06 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 29 May 2017 12:20:06 +0000
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
 <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
 <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>
Message-ID: <CA+RQFfeqid4knmQbdCRT6YwJAeCJao-r2xBNjK2q7_r=5yPx5A@mail.gmail.com>

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/12fc4c35/attachment-0001.html>

From nicoddemus at gmail.com  Mon May 29 13:57:26 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 29 May 2017 17:57:26 +0000
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <CA+RQFfeqid4knmQbdCRT6YwJAeCJao-r2xBNjK2q7_r=5yPx5A@mail.gmail.com>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
 <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
 <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>
 <CA+RQFfeqid4knmQbdCRT6YwJAeCJao-r2xBNjK2q7_r=5yPx5A@mail.gmail.com>
Message-ID: <CA+RQFfcQAX1UepbWnC7tNeyiEQb1p+ENq2OtBrnUGF9dRtZXGA@mail.gmail.com>

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>

From opensource at ronnypfannschmidt.de  Mon May 29 14:26:42 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Mon, 29 May 2017 20:26:42 +0200
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <CA+RQFfcQAX1UepbWnC7tNeyiEQb1p+ENq2OtBrnUGF9dRtZXGA@mail.gmail.com>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
 <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
 <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>
 <CA+RQFfeqid4knmQbdCRT6YwJAeCJao-r2xBNjK2q7_r=5yPx5A@mail.gmail.com>
 <CA+RQFfcQAX1UepbWnC7tNeyiEQb1p+ENq2OtBrnUGF9dRtZXGA@mail.gmail.com>
Message-ID: <c253baba-cbf1-e8d9-b5b7-91518aa21364@ronnypfannschmidt.de>

Hi everyone,

while taking a closer look and trying to understand what cpython does, i
stumbled upon
https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/main.py#L77

so their default runner just crudely pushes a simplefilter onto the
complete system with an crude extra in

https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/runner.py#L159

by now i do believe to just blindly show any deprecation is going to be
a massive disservice to the users (because they do use libraries)

- i believe it should e left to the library-authors to pick what exact
warnings to show
- for pytest - we should actually pick what to show inside pytest,
because we are the "library authors" of pytest

-- Ronny


Am 29.05.2017 um 19:57 schrieb 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
> <mailto: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
>     <mailto: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 <mailto:flub at devork.be>> wrote:
>>
>>             Hi,
>>
>>             On 26 May 2017 at 15:51, Brian Okken
>>             <variedthoughts at gmail.com
>>             <mailto: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 list
>>         pytest-dev at python.org <mailto:pytest-dev at python.org>
>>         https://mail.python.org/mailman/listinfo/pytest-dev
> 

From rpfannsc at redhat.com  Mon May 29 08:26:48 2017
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Mon, 29 May 2017 14:26:48 +0200
Subject: [pytest-dev] pytest-testdirectory fixture
In-Reply-To: <CAAWk_DxnvC6vHk8-Jq3kFAL5d3sPiJB8Z0yeSMbnJFWB_JUG-w@mail.gmail.com>
References: <c0aa4988-089f-83d4-8e61-f6083ec5f400@mortenvp.com>
 <87vaokkw3u.fsf@powell.devork.be>
 <8590cd22-f0d6-43bf-18fb-1c55269cb11d@mortenvp.com>
 <CAAWk_DxnvC6vHk8-Jq3kFAL5d3sPiJB8Z0yeSMbnJFWB_JUG-w@mail.gmail.com>
Message-ID: <CAA10jzOmijtxP+ciJmcDfCf0Raa4kyNUEr0=SO==bbAG249ZNw@mail.gmail.com>

some ideas of the internal plugin are nice to have (like lists of matching
expressions in order)

others are a mess we'd like to clean ourselves - so please if you do, pick
with due scrutiny

Cheers,
Ronny

2017-05-29 13:46 GMT+02:00 Floris Bruynooghe <flub at devork.be>:

> On 29 May 2017 at 13:27, Morten V. Pedersen <morten at mortenvp.com> wrote:
> > Hi Floris,
> > Thanks. Did not know that there was an internal similar thing in pytest.
> I
> > take a look at that, perhaps some things can be improved based on the
> ideas
> > there.
>
> It's in _pytest/pytester.py if you're looking.  But it really is much
> messier then your plugin and too specific to pytest.  Your plugin
> looks much nicer for external use.  I'd not be too eager to copy
> features of the internal plugin unless one of your users actually
> wants them.
>
>
> Cheers,
> Floris
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>



-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170529/cde9e79c/attachment-0001.html>

From me at the-compiler.org  Tue May 30 05:13:03 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 30 May 2017 11:13:03 +0200
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <c253baba-cbf1-e8d9-b5b7-91518aa21364@ronnypfannschmidt.de>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
 <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
 <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>
 <CA+RQFfeqid4knmQbdCRT6YwJAeCJao-r2xBNjK2q7_r=5yPx5A@mail.gmail.com>
 <CA+RQFfcQAX1UepbWnC7tNeyiEQb1p+ENq2OtBrnUGF9dRtZXGA@mail.gmail.com>
 <c253baba-cbf1-e8d9-b5b7-91518aa21364@ronnypfannschmidt.de>
Message-ID: <20170530091302.m4g6bwyric4fszzg@hooch.localdomain>

On Mon, May 29, 2017 at 08:26:42PM +0200, RonnyPfannschmidt wrote:
> Hi everyone,
> 
> while taking a closer look and trying to understand what cpython does, i
> stumbled upon
> https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/main.py#L77
> 
> so their default runner just crudely pushes a simplefilter onto the
> complete system with an crude extra in
> 
> https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/runner.py#L159
> 
> by now i do believe to just blindly show any deprecation is going to be
> a massive disservice to the users (because they do use libraries)
> 
> - i believe it should e left to the library-authors to pick what exact
> warnings to show

I'd still be in favour of turning them on by default, if that's possible
without clashing with existing filters. I don't think it's the job of
libraries to modify warning filters - they already do do decide to show
those warnings, otherwise they wouldn't emit them in the first place.

Other test runners already show them. There's even some discussion about
showing them by default in the REPL, and ipython already seems to do
that:
http://bugs.python.org/issue24294
https://github.com/ipython/ipython/issues/8478

If we don't show them, nobody will see them, and they won't be fixed
before stuff breaks for real. I've reported so many bugs to libraries
which used deprecated stuff - they didn't see the warnings because they
were using pytest with the default settings, and I did because I was
using pytest-warnings. But things shouldn't be that way.

As a data point, looks like it was the same for pytest-asyncio:
https://github.com/pytest-dev/pytest-asyncio/pull/51

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
         I love long mails!  | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170530/f100fd72/attachment.sig>

From opensource at ronnypfannschmidt.de  Tue May 30 05:40:58 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Tue, 30 May 2017 11:40:58 +0200
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <20170530091302.m4g6bwyric4fszzg@hooch.localdomain>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
 <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
 <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>
 <CA+RQFfeqid4knmQbdCRT6YwJAeCJao-r2xBNjK2q7_r=5yPx5A@mail.gmail.com>
 <CA+RQFfcQAX1UepbWnC7tNeyiEQb1p+ENq2OtBrnUGF9dRtZXGA@mail.gmail.com>
 <c253baba-cbf1-e8d9-b5b7-91518aa21364@ronnypfannschmidt.de>
 <20170530091302.m4g6bwyric4fszzg@hooch.localdomain>
Message-ID: <452fca75-c07e-1d98-c20d-db68eb5f3356@ronnypfannschmidt.de>



Am 30.05.2017 um 11:13 schrieb Florian Bruhin:
> On Mon, May 29, 2017 at 08:26:42PM +0200, RonnyPfannschmidt wrote:
>> Hi everyone,
>>
>> while taking a closer look and trying to understand what cpython does, i
>> stumbled upon
>> https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/main.py#L77
>>
>> so their default runner just crudely pushes a simplefilter onto the
>> complete system with an crude extra in
>>
>> https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/runner.py#L159
>>
>> by now i do believe to just blindly show any deprecation is going to be
>> a massive disservice to the users (because they do use libraries)
>>
>> - i believe it should e left to the library-authors to pick what exact
>> warnings to show
> 
> I'd still be in favour of turning them on by default, if that's possible
> without clashing with existing filters. I don't think it's the job of
> libraries to modify warning filters - they already do do decide to show
> those warnings, otherwise they wouldn't emit them in the first place.
> 
> Other test runners already show them. There's even some discussion about
> showing them by default in the REPL, and ipython already seems to do
> that:
> http://bugs.python.org/issue24294
> https://github.com/ipython/ipython/issues/8478
> 
> If we don't show them, nobody will see them, and they won't be fixed
> before stuff breaks for real. I've reported so many bugs to libraries
> which used deprecated stuff - they didn't see the warnings because they
> were using pytest with the default settings, and I did because I was
> using pytest-warnings. But things shouldn't be that way.

py.test should enable its own warnings so people see them
py.test is the "library", so py.test enables the filters

> 
> As a data point, looks like it was the same for pytest-asyncio:
> https://github.com/pytest-dev/pytest-asyncio/pull/51
> 
> Florian
> 

From nicoddemus at gmail.com  Tue May 30 19:46:39 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 30 May 2017 23:46:39 +0000
Subject: [pytest-dev] pytest 3.1 warning capture woes
In-Reply-To: <452fca75-c07e-1d98-c20d-db68eb5f3356@ronnypfannschmidt.de>
References: <CA+RQFfeKqL9T087CTtG1E6+SXRfcv7zcVqwU73BRF89a4FaW0Q@mail.gmail.com>
 <72C9AB99-979D-4041-AE50-0B67D5F414DD@gmail.com>
 <CAAWk_Dwi8cPy+trJCSDqfabp9JJvvhth5GCxMZji1Y=wmsJi2g@mail.gmail.com>
 <CA+RQFfes5CkrQ8LbLJY1d5iP0s_DwF0Cn9jDpB2qayGLdDK6DQ@mail.gmail.com>
 <a4205283-e212-e671-480f-338fab2523d8@ronnypfannschmidt.de>
 <CA+RQFfeqid4knmQbdCRT6YwJAeCJao-r2xBNjK2q7_r=5yPx5A@mail.gmail.com>
 <CA+RQFfcQAX1UepbWnC7tNeyiEQb1p+ENq2OtBrnUGF9dRtZXGA@mail.gmail.com>
 <c253baba-cbf1-e8d9-b5b7-91518aa21364@ronnypfannschmidt.de>
 <20170530091302.m4g6bwyric4fszzg@hooch.localdomain>
 <452fca75-c07e-1d98-c20d-db68eb5f3356@ronnypfannschmidt.de>
Message-ID: <CA+RQFfeasAt9TqB6VAkUe879fdMXUbE7tuxUmEAw3Fb_CX2LkA@mail.gmail.com>

On Tue, May 30, 2017 at 6:41 AM RonnyPfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

>
> > I'd still be in favour of turning them on by default, if that's possible
> > without clashing with existing filters. I don't think it's the job of
> > libraries to modify warning filters - they already do do decide to show
> > those warnings, otherwise they wouldn't emit them in the first place.
> >
> > Other test runners already show them. There's even some discussion about
> > showing them by default in the REPL, and ipython already seems to do
> > that:
> > http://bugs.python.org/issue24294
> > https://github.com/ipython/ipython/issues/8478
> >
> > If we don't show them, nobody will see them, and they won't be fixed
> > before stuff breaks for real. I've reported so many bugs to libraries
> > which used deprecated stuff - they didn't see the warnings because they
> > were using pytest with the default settings, and I did because I was
> > using pytest-warnings. But things shouldn't be that way.
>
> py.test should enable its own warnings so people see them
> py.test is the "library", so py.test enables the filters
>

I agree with Florian that pytest should strive to generate deprecation
warnings by default for the reasons he mentions, but I think if we are
going to do it we should do it slowly and in careful steps. As a testing
framework we just learned that it is easy to mess up with the warnings
filters and break test suites which configure their own filters.

I don't see an easy way to introduce this with the builtin warning filters
without risking breaking existing suites, so we would have to figure a
different way to implement it (monkey patching comes to mind). To introduce
it we should add an option to enable the feature in a minor release,
defaulting to False, and then perhaps consider turning it on by default in
a major version.

That's my 2 cents at least.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170530/4537c697/attachment.html>

From nicoddemus at gmail.com  Wed May 31 07:56:15 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 31 May 2017 11:56:15 +0000
Subject: [pytest-dev] pytest 3.1.1 released!
Message-ID: <CA+RQFfdTNh_rRocPcpDMZ-D-yivp47=mDN1-ia9iqmNM+Nj2Og@mail.gmail.com>

pytest 3.1.1 has just been released to PyPI.

This is a bug-fix release, being a drop-in replacement. To upgrade::

  pip install --upgrade pytest

The full changelog is available at
http://doc.pytest.org/en/latest/changelog.html.

Thanks to all who contributed to this release, among them:

* Bruno Oliveira
* Florian Bruhin
* Floris Bruynooghe
* Jason R. Coombs
* Ronny Pfannschmidt
* wanghui


Happy testing,
The pytest Development Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170531/c36c0897/attachment.html>

From nicoddemus at gmail.com  Wed May 31 11:51:36 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 31 May 2017 15:51:36 +0000
Subject: [pytest-dev] pytest.org redirect request (#2453)
Message-ID: <CA+RQFffJU4e51dyxX_C4mnT9_CdVCMCRvFXE9DPZ7NDAWUYNhg@mail.gmail.com>

Hi everyone,

An issue has been raised in the bug tracker asking to redirect
docs.pytest.org/latest/* to docs.pytest.org/en/latest/*:

https://github.com/pytest-dev/pytest/issues/2453

Whoever has powers to that change the redirect rules could take a look
please? Thanks!

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170531/3aaace7e/attachment.html>