From nicoddemus at gmail.com  Thu Sep  6 08:42:50 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 6 Sep 2018 09:42:50 -0300
Subject: [pytest-dev] pytest 3.8.0 released!
Message-ID: <CA+RQFfd6YnxKhQdrvJi9P7fn9ENfCCowyp4bYEwfC1F4tL+Rsg@mail.gmail.com>

The pytest team is proud to announce the 3.8.0 release!

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

This release introduces a refactoring of warnings generated by pytest
itself, making clearer when features are deprecated and when they are
planned for removal. Also fixes a number of long standing issues with
warnings capture.

Users are encouraged to take a look at the CHANGELOG:

    https://docs.pytest.org/en/latest/changelog.html

For complete documentation, please visit:

    https://docs.pytest.org/en/latest/

As usual, you can upgrade from pypi via:

    pip install -U pytest

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

* Anthony Sottile
* Bruno Oliveira
* CrazyMerlyn
* Daniel Hahler
* Fabio Zadrozny
* Jeffrey Rackauckas
* Ronny Pfannschmidt
* Virgil Dupras
* dhirensr
* hoefling
* wim glenn


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

From maiksensi at gmail.com  Thu Sep  6 13:26:29 2018
From: maiksensi at gmail.com (Maik Figura)
Date: Thu, 6 Sep 2018 19:26:29 +0200
Subject: [pytest-dev] Hacktoberfest - Beginner Issues
Message-ID: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>

Hey everyone,

I noticed that the issue tracker almost hit 500 issues. Would it be good
to discuss how to handle issues in general (follow ups, etc) and on how
to maybe reduce the amount of outdated issues (I am not even sure there
are outdated ones...). Do we maybe have examples how other projects do
this? Or maybe this was already discussed and I just missed it?


Best,

Maik.


From maiksensi at gmail.com  Thu Sep  6 13:28:42 2018
From: maiksensi at gmail.com (Maik Figura)
Date: Thu, 6 Sep 2018 19:28:42 +0200
Subject: [pytest-dev] Hacktoberfest - Beginner Issues
In-Reply-To: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>
References: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>
Message-ID: <d691b384-7b13-9a9f-1838-c5aaf99cdfdb@gmail.com>

Excuse the wrong topic... hmpf. Can I change it?


On 06.09.2018 19:26, Maik Figura wrote:
> Hey everyone,
>
> I noticed that the issue tracker almost hit 500 issues. Would it be good
> to discuss how to handle issues in general (follow ups, etc) and on how
> to maybe reduce the amount of outdated issues (I am not even sure there
> are outdated ones...). Do we maybe have examples how other projects do
> this? Or maybe this was already discussed and I just missed it?
>
>
> Best,
>
> Maik.
>


From nicoddemus at gmail.com  Thu Sep  6 14:20:50 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 6 Sep 2018 15:20:50 -0300
Subject: [pytest-dev] Hacktoberfest - Beginner Issues
In-Reply-To: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>
References: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>
Message-ID: <CA+RQFffB77by8EZSJHVQfkAGqsb0Sx7yRYuxqMDU4R_o89KU4A@mail.gmail.com>

On Thu, Sep 6, 2018 at 2:26 PM Maik Figura <maiksensi at gmail.com> wrote:

> Hey everyone,
>
> I noticed that the issue tracker almost hit 500 issues. Would it be good
> to discuss how to handle issues in general (follow ups, etc) and on how
> to maybe reduce the amount of outdated issues (I am not even sure there
> are outdated ones...). Do we maybe have examples how other projects do
> this? Or maybe this was already discussed and I just missed it?
>
>
Hi Maik,

(I'm adressing the contents of the email, not the title :))

The number of open issues is something that bugs me. One of the reasons
that labels like "question" and "needs information" were created was that
we could periodically go over issues marked with them and close if they
have been inactive after some time, but this is something that has to be
done regularly.

I would love to know how other projects which also face a large number of
issues deal with this.

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

From brianna.laugher at gmail.com  Sun Sep  9 02:43:04 2018
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Sun, 9 Sep 2018 16:43:04 +1000
Subject: [pytest-dev] Hacktoberfest - Beginner Issues
In-Reply-To: <CA+RQFffB77by8EZSJHVQfkAGqsb0Sx7yRYuxqMDU4R_o89KU4A@mail.gmail.com>
References: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>
 <CA+RQFffB77by8EZSJHVQfkAGqsb0Sx7yRYuxqMDU4R_o89KU4A@mail.gmail.com>
Message-ID: <CAPjwCjtp8H+h9xFk6_-7KffJeeV457W63UnJ3kJ6uF5fwhLT6w@mail.gmail.com>

I have seen a lot of projects use something like
https://github.com/apps/stale to auto-close issues after a certain amount
of time has passed without activity.

On Fri, 7 Sep 2018 at 04:21, Bruno Oliveira <nicoddemus at gmail.com> wrote:

>
> On Thu, Sep 6, 2018 at 2:26 PM Maik Figura <maiksensi at gmail.com> wrote:
>
>> Hey everyone,
>>
>> I noticed that the issue tracker almost hit 500 issues. Would it be good
>> to discuss how to handle issues in general (follow ups, etc) and on how
>> to maybe reduce the amount of outdated issues (I am not even sure there
>> are outdated ones...). Do we maybe have examples how other projects do
>> this? Or maybe this was already discussed and I just missed it?
>>
>>
> Hi Maik,
>
> (I'm adressing the contents of the email, not the title :))
>
> The number of open issues is something that bugs me. One of the reasons
> that labels like "question" and "needs information" were created was that
> we could periodically go over issues marked with them and close if they
> have been inactive after some time, but this is something that has to be
> done regularly.
>
> I would love to know how other projects which also face a large number of
> issues deal with this.
>
> Cheers,
> Bruno.
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>


-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180909/20e31a3a/attachment.html>

From brianna.laugher at gmail.com  Sun Sep  9 02:44:16 2018
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Sun, 9 Sep 2018 16:44:16 +1000
Subject: [pytest-dev] Hacktoberfest - Beginner Issues
In-Reply-To: <CAPjwCjtp8H+h9xFk6_-7KffJeeV457W63UnJ3kJ6uF5fwhLT6w@mail.gmail.com>
References: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>
 <CA+RQFffB77by8EZSJHVQfkAGqsb0Sx7yRYuxqMDU4R_o89KU4A@mail.gmail.com>
 <CAPjwCjtp8H+h9xFk6_-7KffJeeV457W63UnJ3kJ6uF5fwhLT6w@mail.gmail.com>
Message-ID: <CAPjwCjvzKcd3xCSFkaxaWF4hiqT50WR2WbTOqSQ3At04miEdpQ@mail.gmail.com>

Some projects have a bug triaging guide, eg
http://docs.hood.ie/en/latest/developers/TRIAGING.html . Writing up the
existing process (eg intention of existing labels) may help more people
carry out bug triage.

On Sun, 9 Sep 2018 at 16:43, Brianna Laugher <brianna.laugher at gmail.com>
wrote:

> I have seen a lot of projects use something like
> https://github.com/apps/stale to auto-close issues after a certain amount
> of time has passed without activity.
>
> On Fri, 7 Sep 2018 at 04:21, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>
>>
>> On Thu, Sep 6, 2018 at 2:26 PM Maik Figura <maiksensi at gmail.com> wrote:
>>
>>> Hey everyone,
>>>
>>> I noticed that the issue tracker almost hit 500 issues. Would it be good
>>> to discuss how to handle issues in general (follow ups, etc) and on how
>>> to maybe reduce the amount of outdated issues (I am not even sure there
>>> are outdated ones...). Do we maybe have examples how other projects do
>>> this? Or maybe this was already discussed and I just missed it?
>>>
>>>
>> Hi Maik,
>>
>> (I'm adressing the contents of the email, not the title :))
>>
>> The number of open issues is something that bugs me. One of the reasons
>> that labels like "question" and "needs information" were created was that
>> we could periodically go over issues marked with them and close if they
>> have been inactive after some time, but this is something that has to be
>> done regularly.
>>
>> I would love to know how other projects which also face a large number of
>> issues deal with this.
>>
>> Cheers,
>> Bruno.
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
>
> --
> They've just been waiting in a mountain for the right moment:
> http://modernthings.org/
>


-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180909/c45ebd5e/attachment.html>

From brianna.laugher at gmail.com  Sun Sep  9 02:50:52 2018
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Sun, 9 Sep 2018 16:50:52 +1000
Subject: [pytest-dev] Fwd: [CodeTriage] Help triage pytest-dev/pytest
In-Reply-To: <5b94bffbb3a53_43fb34ea19f281551f8@9a76b93b-a604-4d50-beaf-68531f698e06.mail>
References: <5b94bffbb3a53_43fb34ea19f281551f8@9a76b93b-a604-4d50-beaf-68531f698e06.mail>
Message-ID: <CAPjwCjsuAZuDx0wgxv_CRYvj_vuV4Sikw=AfOFdJ-8ViCpV-xw@mail.gmail.com>

On the topic of issue triage, this is a service we could promote people to
use. But I guess it's a question if the problem is more rate of new issues
or old issues never getting closed.

Brianna


---------- Forwarded message ---------
From: CodeTriage <noreply at codetriage.com>
Date: Sun, 9 Sep 2018 at 16:38
Subject: [CodeTriage] Help triage pytest-dev/pytest
To: <brianna.laugher at gmail.com>


Hello pfctdayelise,
Repo added to CodeTriage!

Thank you for adding pytest-dev/pytest to CodeTriage. If you want to get
more people helping out with this repo, we suggest adding a badge to the
repo?s readme. Here is the markdown:

[![Open Source Helpers
badge](https://codetriage.com/pytest-dev/pytest/badges/users.svg)](https://codetriage.com/pytest-dev/pytest)

You can view an the badge on the CodeTriage page for pytest
<https://u307627.ct.sendgrid.net/wf/click?upn=MUrV-2BnW5j8SEy7InNvMchphxrykvX4sYF7UPgiGeGjn1K6gbCGbkCErfbfdY1OtK_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6k9rm6m6oBvX6cRHikYkrxiXDxoRttnlwldlbIiMuaSzRsBSNpKGqxChlpsVrGNZcoPvYGsqAU8jIf6L9Plw-2FSuHt-2BL8WeCITa7rDCM16L4fgIb0o-2BbeDyUPUc-2Fe2-2FEURxUZz-2BztOS-2B8wLhuiXpmgAA-3D>
.

If pytest has a ?contributing section? or docs on helping such as
contributing.md, it helps to put a sentence or two encouraging people to
subscribe to your repo:

You can triage issues which may include reproducing bug reports
or asking for vital information, such as version numbers or
reproduction instructions. If you would like to start triaging
issues, one easy way to get started is to [subscribe to pytest on
CodeTriage](https://codetriage.com/pytest-dev/pytest).

The more people you have subscribed to this repo on CodeTriage, the more
help it will get on this project. The more ??s the better.
------------------------------
You subscribed to pytest on CodeTriage!

You signed up to help triage GitHub issues on pytest-dev/pytest
<https://u307627.ct.sendgrid.net/wf/click?upn=E2E2DIkTqIajPU6hMNRcRHG-2Flbe4QlJNOKZoJedwfv-2BsTymI-2FkInAaIFtKHAugpk_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6uvAdWd0DItR6aL-2B1dBfIXhtFKbVjEOiN1wcml7j-2BjMbCJS0s1N-2F2beweSFrC4TlT0oqgRaUw1euc8SfXLUglegv-2BtyO-2B2cVZyZPyogTY-2BW2xHMstc0SF7XLSvDYczEEtPnst6d5ugfta0eGRnTxACQ-3D>.
That?s pretty awesome.

What?s next? You?ll get issues sent to your inbox periodically like this
one:

*pytest-dev/pytest#2449* warnings: support for logging.captureWarnings
<https://u307627.ct.sendgrid.net/wf/click?upn=E2E2DIkTqIajPU6hMNRcRHG-2Flbe4QlJNOKZoJedwfv-2F7bAWZOlBnZ7OnRzvgfq49RKqnnFx8F4YG19mmjou6HA-3D-3D_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6urCtfPVWQgr2f9OYacXqSbxtNOeN9AAW2WiU0hxKhIOnbMtftM7pfAVR4FhP0EApgokyUBRK6jURXeLqg9t3rWPER8zfHpi4nUzQqSESHbpNlOJjpqs-2Fih4hfuFpAtEFkSCfG40uSQi0NTplX73G04-3D>

The rate at which we send emails backs off automatically when you get busy.
You can also set you prefered email rate in your user settings.

What do you do with an issue when it gets in your inbox? Try to triage it.
How To Triage?

First, carefully read over the issue, title, and description, if there are
any comments read over all the comments, carefully. If a member of this
repo is engaging actively there is no need to do anything, leaving a
comment in the issue would just add to the clutter.

If the issue hasn?t been updated in awhile, or if no one has commented
consider the issue, if it is a bug try to reproduce it. If it is a pull
request consider what an alternate implementation might look like. If there
is something you don?t understand about the issue and feel others will have
that same question please leave your question in the comments. Be as
descriptive as possible. Comments like ?I don?t understand this? are not
helpful and counter productive. A better comment might be ?Can you help me
understand a use case for this??.

If you can reproduce the issue or you believe it is a good pull request,
add a comment and say why you think that is. Try to stay positive while
triaging issues, ask questions before you downvote something. If you do
decide to ? or ? on an issue, leave a comment as to why you feel that
way. Issues are for social coding, if you help someone make better issues,
you?re helping the community.

If the issue goes stale, leave a comment asking if it is still a problem.
If you get no response for a number of days, you can leave another comment
suggesting to the repo owner that they should close the issue.

Read more about Fixing Open Source Issues via Triage
<https://u307627.ct.sendgrid.net/wf/click?upn=gvZlbyjGw-2B4Vj3enF605apAySa8EIl3uCB8-2FIVaWLInepWakSnDUunb6d4SwZwfny8a8jQfW-2B39jh-2Fj1ETE1dMnCXqvqcpUZ6-2F8a79T-2B8qw-3D_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6njfNDHKgjkHeDwW4NTkG1O8fuzjK239ABUALPJoZTntHlhAQ8NvWTztfUDldY06jb-2Fq1Frm6PG0lq5iAzRWY1baJ3uu4VhcO0VV8oCOjkabxc5Z1mkDb6BtCyBOV9Bo0FULAU-2B03ShL-2FmusBB1hYWw-3D>
.
Goals of Triage

   - Help share the weight of maintaining a project
   - Minimize un-needed issues
   - Prevent stale issues
   - Encourage productive communication
   - Teach good citizenship
   - To become a better coder

Go forth and make the world a better place

Sincerely,

schneems
<https://u307627.ct.sendgrid.net/wf/click?upn=HwDhLwOSLCgrJQpXhIJyyTVZeHekFO4Tct7bd9yR32c-3D_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6kDfnf8ChkDbchWJJ1bmbkKIVjVIljXNjDDgV9Ig9Fwk2bUkaJlA0GAduAbEdgQZYngO1m37gM2u9NhfuNLPPa3YNWevtInhWk1fTCF8fueUUTL4DsZa7VaJDhPoxOiTps9OXoynn-2BkwlXnsStjF738-3D>



-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180909/95c65bff/attachment-0001.html>

From opensource at ronnypfannschmidt.de  Sun Sep  9 05:37:01 2018
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Sun, 9 Sep 2018 11:37:01 +0200
Subject: [pytest-dev] Fwd: [CodeTriage] Help triage pytest-dev/pytest
In-Reply-To: <CAPjwCjsuAZuDx0wgxv_CRYvj_vuV4Sikw=AfOFdJ-8ViCpV-xw@mail.gmail.com>
References: <5b94bffbb3a53_43fb34ea19f281551f8@9a76b93b-a604-4d50-beaf-68531f698e06.mail>
 <CAPjwCjsuAZuDx0wgxv_CRYvj_vuV4Sikw=AfOFdJ-8ViCpV-xw@mail.gmail.com>
Message-ID: <0b661b46-81a2-4314-5399-dfaa9caa7366@ronnypfannschmidt.de>

Hi Brianna,

i believe we have trouble closing older issues as we have quite a
backlog on technical debt thats hard to solve in a non-disruptive manner,
as such various valid issues just tend to stay open.


-- ROonny


Am 09.09.2018 um 08:50 schrieb Brianna Laugher:
> On the topic of issue triage, this is a service we could promote
> people to use. But I guess it's a question if the problem is more rate
> of new issues or old issues never getting closed.
>
> Brianna
>
>
> ---------- Forwarded message ---------
> From: *CodeTriage* <noreply at codetriage.com
> <mailto:noreply at codetriage.com>>
> Date: Sun, 9 Sep 2018 at 16:38
> Subject: [CodeTriage] Help triage pytest-dev/pytest
> To: <brianna.laugher at gmail.com <mailto:brianna.laugher at gmail.com>>
>
>
> Hello pfctdayelise,
>
>
>     Repo added to CodeTriage!
>
> Thank you for adding pytest-dev/pytest to CodeTriage. If you want to
> get more people helping out with this repo, we suggest adding a badge
> to the repo?s readme. Here is the markdown:
>
> [![Open Source Helpers badge](https://codetriage.com/pytest-dev/pytest/badges/users.svg)](https://codetriage.com/pytest-dev/pytest
> <https://codetriage.com/pytest-dev/pytest/badges/users.svg%29%5D%28https://codetriage.com/pytest-dev/pytest>)
>
> You can view an the badge on the CodeTriage page for pytest
> <https://u307627.ct.sendgrid.net/wf/click?upn=MUrV-2BnW5j8SEy7InNvMchphxrykvX4sYF7UPgiGeGjn1K6gbCGbkCErfbfdY1OtK_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6k9rm6m6oBvX6cRHikYkrxiXDxoRttnlwldlbIiMuaSzRsBSNpKGqxChlpsVrGNZcoPvYGsqAU8jIf6L9Plw-2FSuHt-2BL8WeCITa7rDCM16L4fgIb0o-2BbeDyUPUc-2Fe2-2FEURxUZz-2BztOS-2B8wLhuiXpmgAA-3D>.
>
> If pytest has a ?contributing section? or docs on helping such as
> |contributing.md|, it helps to put a sentence or two encouraging
> people to subscribe to your repo:
>
> You can triage issues which may include reproducing bug reports
> or asking for vital information, such as version numbers or
> reproduction instructions. If you would like to start triaging
> issues, one easy way to get started is to [subscribe to pytest on CodeTriage](https://codetriage.com/pytest-dev/pytest).
>
> The more people you have subscribed to this repo on CodeTriage, the
> more help it will get on this project. The more ??s the better.
>
> ------------------------------------------------------------------------
>
>
>     You subscribed to pytest on CodeTriage!
>
> You signed up to help triage GitHub issues on pytest-dev/pytest
> <https://u307627.ct.sendgrid.net/wf/click?upn=E2E2DIkTqIajPU6hMNRcRHG-2Flbe4QlJNOKZoJedwfv-2BsTymI-2FkInAaIFtKHAugpk_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6uvAdWd0DItR6aL-2B1dBfIXhtFKbVjEOiN1wcml7j-2BjMbCJS0s1N-2F2beweSFrC4TlT0oqgRaUw1euc8SfXLUglegv-2BtyO-2B2cVZyZPyogTY-2BW2xHMstc0SF7XLSvDYczEEtPnst6d5ugfta0eGRnTxACQ-3D>.
> That?s pretty awesome.
>
> What?s next? You?ll get issues sent to your inbox periodically like
> this one:
>
> *pytest-dev/pytest#2449* warnings: support for logging.captureWarnings
> <https://u307627.ct.sendgrid.net/wf/click?upn=E2E2DIkTqIajPU6hMNRcRHG-2Flbe4QlJNOKZoJedwfv-2F7bAWZOlBnZ7OnRzvgfq49RKqnnFx8F4YG19mmjou6HA-3D-3D_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6urCtfPVWQgr2f9OYacXqSbxtNOeN9AAW2WiU0hxKhIOnbMtftM7pfAVR4FhP0EApgokyUBRK6jURXeLqg9t3rWPER8zfHpi4nUzQqSESHbpNlOJjpqs-2Fih4hfuFpAtEFkSCfG40uSQi0NTplX73G04-3D>
>
> The rate at which we send emails backs off automatically when you get
> busy. You can also set you prefered email rate in your user settings.
>
> What do you do with an issue when it gets in your inbox? Try to triage it.
>
>
>     How To Triage?
>
> First, carefully read over the issue, title, and description, if there
> are any comments read over all the comments, carefully. If a member of
> this repo is engaging actively there is no need to do anything,
> leaving a comment in the issue would just add to the clutter.
>
> If the issue hasn?t been updated in awhile, or if no one has commented
> consider the issue, if it is a bug try to reproduce it. If it is a
> pull request consider what an alternate implementation might look
> like. If there is something you don?t understand about the issue and
> feel others will have that same question please leave your question in
> the comments. Be as descriptive as possible. Comments like ?I don?t
> understand this? are not helpful and counter productive. A better
> comment might be ?Can you help me understand a use case for this??.
>
> If you can reproduce the issue or you believe it is a good pull
> request, add a comment and say why you think that is. Try to stay
> positive while triaging issues, ask questions before you downvote
> something. If you do decide to ? or ? on an issue, leave a comment
> as to why you feel that way. Issues are for social coding, if you help
> someone make better issues, you?re helping the community.
>
> If the issue goes stale, leave a comment asking if it is still a
> problem. If you get no response for a number of days, you can leave
> another comment suggesting to the repo owner that they should close
> the issue.
>
> Read more about Fixing Open Source Issues via Triage
> <https://u307627.ct.sendgrid.net/wf/click?upn=gvZlbyjGw-2B4Vj3enF605apAySa8EIl3uCB8-2FIVaWLInepWakSnDUunb6d4SwZwfny8a8jQfW-2B39jh-2Fj1ETE1dMnCXqvqcpUZ6-2F8a79T-2B8qw-3D_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6njfNDHKgjkHeDwW4NTkG1O8fuzjK239ABUALPJoZTntHlhAQ8NvWTztfUDldY06jb-2Fq1Frm6PG0lq5iAzRWY1baJ3uu4VhcO0VV8oCOjkabxc5Z1mkDb6BtCyBOV9Bo0FULAU-2B03ShL-2FmusBB1hYWw-3D>.
>
>
>     Goals of Triage
>
>   * Help share the weight of maintaining a project
>   * Minimize un-needed issues
>   * Prevent stale issues
>   * Encourage productive communication
>   * Teach good citizenship
>   * To become a better coder
>
> Go forth and make the world a better place
>
> Sincerely,
>
> schneems
> <https://u307627.ct.sendgrid.net/wf/click?upn=HwDhLwOSLCgrJQpXhIJyyTVZeHekFO4Tct7bd9yR32c-3D_wXFy2nOJ1XVOQei6Rg8EwVYdZS-2FdnbpAFtydSKD-2BGv2SPw5xO9m62RzBky8FRXoCXbX8o9H9Myw1SfS-2B1bsi6kDfnf8ChkDbchWJJ1bmbkKIVjVIljXNjDDgV9Ig9Fwk2bUkaJlA0GAduAbEdgQZYngO1m37gM2u9NhfuNLPPa3YNWevtInhWk1fTCF8fueUUTL4DsZa7VaJDhPoxOiTps9OXoynn-2BkwlXnsStjF738-3D>
>
>
>
>
> -- 
> They've just been waiting in a mountain for the right moment:
> http://modernthings.org/
>
>
> _______________________________________________
> 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/20180909/c7d17bac/attachment.html>

From nicoddemus at gmail.com  Thu Sep 13 21:52:53 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 13 Sep 2018 22:52:53 -0300
Subject: [pytest-dev] pytest.raises message parameter
Message-ID: <CA+RQFfeZ3SvQKcKDNp_gGGNJRAC0OEUcYcw7VRUPSCL-93zjzQ@mail.gmail.com>

Hi everyone,

When using `pytest.raises`, it seems a lot of users confuse the parameter
`message` (a message to display if the with block finishes with no
exception) and `match` (a regular expression that the exception should
match), using the former when they meant the latter. This is very dangerous
as provides false positives.

https://docs.pytest.org/en/latest/reference.html#pytest-raises

Roman Yurchak posted a detailed example including PRs of projects that were
using the parameter incorrectly (using `message` when they meant `match`),
so this seems like a common problem.

So we have two proposals:

1, Deprecate `message` and use another parameter name. Little tricky to
find a suitable name that cannot be confused with `match`, but this is a
safe approach.

2. Removing the parameter altogether (after deprecating it). This would
make it match (heh) `pytest.warn`'s signature as well, which is a bonus.
This is an excellent option in the long term if there are no good use-cases
for it.

It would be helpful if people can provide good use cases to keep
`message`/`show_failure_message`, around, and also their opinion about this
matter.

I would like to keep the discussion in the issue itself, I'm using the
mailing list because few people here follow the GitHub issues by the sheer
amount of it:

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

So let's please not continue this discussion here and use the issue itself.
Thanks!

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

From nicoddemus at gmail.com  Thu Sep 20 07:59:53 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 20 Sep 2018 08:59:53 -0300
Subject: [pytest-dev] VS Team Services
Message-ID: <CA+RQFfcFHEvQ_0h2XRTR9WMwPt8g-69cR6QoaSQMNH6qVZJ46w@mail.gmail.com>

Hi everyone,

Just to let the other core-devs know that I have created a pytest-dev
organization at Visual Studio Team Services. I'm just reserving the name
for now in case we want to make use of VS Team Services in the future (like
tox is doing right now).

I've sent invites to Holger and Ronny to reduce bus factor, but if others
would like to play around and want access just let me know.

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

From brianna.laugher at gmail.com  Fri Sep 21 04:35:39 2018
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Fri, 21 Sep 2018 18:35:39 +1000
Subject: [pytest-dev] Hacktober coming up
Message-ID: <CAPjwCjsqq6hO81Af126CKdnydcB=mN1xQe4ZEc1EBOUbUg3+_g@mail.gmail.com>

Hi,

I was reminded today that github's month long event encouraging people to
submit PRs to open source projects will begin once again in a week or so. I
am not sure how much increased activity was notice last year, but perhaps
it would be prudent to do a bit of extra issue grooming if we can.
Especially labeling beginner friendly/easy issues.

Cheers
Brianna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180921/941a20b6/attachment.html>

From Nikolaus at rath.org  Fri Sep 21 07:44:13 2018
From: Nikolaus at rath.org (Nikolaus Rath)
Date: Fri, 21 Sep 2018 12:44:13 +0100
Subject: [pytest-dev] Accessing markers in pytest_generate_tests
Message-ID: <87r2hndqia.fsf@vostro.rath.org>

Hello,

I am currently using code like this:

def pytest_generate_tests(metafunc, _info_cache=[]):
    # [...]
    
    fn = metafunc.function
  
    do_something(fn.with_backend.kwargs)
    for spec in fn.with_backend.args:
       # [...]

This has started to emit a warning:

/home/nikratio/in-progress/s3ql/tests/t1_backends.py:118: RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged marks which are hard to deal with correctly.
Please use node.get_closest_marker(name) or node.iter_markers(name).
Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
  for spec in fn.with_backend.args:


In my case, the correction solution seems to be to use the
get_closest_marker() method instead. However, this is defined for Node -
neither the metafunc nor the metafunc.function objects have such a
method.

What's the recommended way to access markers in pytest_generate_tests?

Best,
-Nikolaus


-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From opensource at ronnypfannschmidt.de  Fri Sep 21 18:06:51 2018
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Sat, 22 Sep 2018 00:06:51 +0200
Subject: [pytest-dev] Accessing markers in pytest_generate_tests
In-Reply-To: <87r2hndqia.fsf@vostro.rath.org>
References: <87r2hndqia.fsf@vostro.rath.org>
Message-ID: <bb6f63913f1980d86a01979169c93a2e98d44d0f.camel@ronnypfannschmidt.de>

Am Freitag, den 21.09.2018, 12:44 +0100 schrieb Nikolaus Rath:
> Hello,
> 
> I am currently using code like this:
> 
> def pytest_generate_tests(metafunc, _info_cache=[]):
>     # [...]
>     
>     fn = metafunc.function
>   
>     do_something(fn.with_backend.kwargs)
>     for spec in fn.with_backend.args:
>        # [...]
> 
> This has started to emit a warning:
> 
> /home/nikratio/in-progress/s3ql/tests/t1_backends.py:118:
> RemovedInPytest4Warning: MarkInfo objects are deprecated as they
> contain merged marks which are hard to deal with correctly.
> Please use node.get_closest_marker(name) or node.iter_markers(name).
> Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
>   for spec in fn.with_backend.args:
> 
> 
> In my case, the correction solution seems to be to use the
> get_closest_marker() method instead. However, this is defined for
> Node -
> neither the metafunc nor the metafunc.function objects have such a
> method.
> 
> What's the recommended way to access markers in
> pytest_generate_tests?

metafunc.definition.get_closest_marker(...) should do

-- Ronny

> 
> Best,
> -Nikolaus
> 
> 


From philosophe at gmail.com  Sat Sep 22 12:19:00 2018
From: philosophe at gmail.com (Derek Sisson)
Date: Sat, 22 Sep 2018 09:19:00 -0700
Subject: [pytest-dev] keeping passwords out of code
Message-ID: <CAGf+Vg3rHkXuP0xTt3JzhfLbT9hvaQ1ZmPbfUYP55mgsk+febw@mail.gmail.com>

Hi,

I have an end-to-end test framework built on top of pytest, and a big
challenge is managing application passwords while keeping them out of the
code base.

I deal with multiple applications and services, on multiple tiers (staging,
production, etc.), so I have a large set of user-password pairs to manage.

I currently use a local yaml file, with passwords keyed to account ids,
along with a data model of users in the codebase keyed to the same IDs. My
conftest queries the yaml file with the ids to grab the passwords, and it's
set up to throw exceptions if there is anything out of sync between the
data model and the yaml file data.

Cumbersome, but works.... locally. I need to port the framework to Jenkins,
so I need a better and secure system.

Suggestions on better ways of managing passwords and secrets in a
pytest/jenkins context?

thanks,
--derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180922/13a80f15/attachment.html>

From ankitgoel616 at gmail.com  Sat Sep 22 15:55:47 2018
From: ankitgoel616 at gmail.com (Ankit Goel)
Date: Sun, 23 Sep 2018 01:25:47 +0530
Subject: [pytest-dev] pytest 3.8.1 released
Message-ID: <CAMbyYKPRSD3zRXzuWr_7L9ZkiJ4v2+YHzBwn6m3Obo5xqOQd5Q@mail.gmail.com>

pytest 3.8.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
https://docs.pytest.org/en/latest/changelog.html.

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

* Ankit Goel
* Anthony Sottile
* Bruno Oliveira
* Daniel Hahler
* Maximilian Albert
* Ronny Pfannschmidt
* William Jamir Silva
* wim glenn


Happy testing,
The pytest Development Team

From nicoddemus at gmail.com  Sun Sep 23 09:12:24 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sun, 23 Sep 2018 10:12:24 -0300
Subject: [pytest-dev] pytest Python 2.7 support (poll)
Message-ID: <CA+RQFfej-bUPL739R=MdP_8WHdOPWOxWpHnntYsk4Upk3BuMHw@mail.gmail.com>

Hi everyone,

There's a poll on twitter regarding when pytest should drop Python 2.7
support: https://twitter.com/ossronny/status/1043837215175057408

I urge everyone who uses pytest to cast their vote!

Important to note that even when pytest drops support, Python 2.7 users
will still be able to use old pytest versions (in fact pip will always
install a compatible version automatically).

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

From nikolaus at rath.org  Sun Sep 23 09:49:42 2018
From: nikolaus at rath.org (Nikolaus Rath)
Date: Sun, 23 Sep 2018 14:49:42 +0100
Subject: [pytest-dev] Accessing markers in pytest_generate_tests
In-Reply-To: <bb6f63913f1980d86a01979169c93a2e98d44d0f.camel@ronnypfannschmidt.de>
References: <87r2hndqia.fsf@vostro.rath.org>
 <bb6f63913f1980d86a01979169c93a2e98d44d0f.camel@ronnypfannschmidt.de>
Message-ID: <1537710582.2167267.1517689520.4760B467@webmail.messagingengine.com>

On Fri, 21 Sep 2018, at 23:06, Ronny Pfannschmidt wrote:
> Am Freitag, den 21.09.2018, 12:44 +0100 schrieb Nikolaus Rath:
> > Hello,
> > 
> > I am currently using code like this:
> > 
> > def pytest_generate_tests(metafunc, _info_cache=[]):
> >     # [...]
> >     
> >     fn = metafunc.function
> >   
> >     do_something(fn.with_backend.kwargs)
> >     for spec in fn.with_backend.args:
> >        # [...]
> > 
> > This has started to emit a warning:
> > 
> > /home/nikratio/in-progress/s3ql/tests/t1_backends.py:118:
> > RemovedInPytest4Warning: MarkInfo objects are deprecated as they
> > contain merged marks which are hard to deal with correctly.
> > Please use node.get_closest_marker(name) or node.iter_markers(name).
> > Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
> >   for spec in fn.with_backend.args:
> > 
> > 
> > In my case, the correction solution seems to be to use the
> > get_closest_marker() method instead. However, this is defined for
> > Node -
> > neither the metafunc nor the metafunc.function objects have such a
> > method.
> > 
> > What's the recommended way to access markers in
> > pytest_generate_tests?
> 
> metafunc.definition.get_closest_marker(...) should do

Works like a charm, thanks!



--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

From opensource at ronnypfannschmidt.de  Sun Sep 23 13:49:30 2018
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Sun, 23 Sep 2018 19:49:30 +0200
Subject: [pytest-dev] [TIP] pytest Python 2.7 support (poll) (re-sent)
In-Reply-To: <1537721859.3861.1.camel@daknuett.eu>
References: <CA+RQFfej-bUPL739R=MdP_8WHdOPWOxWpHnntYsk4Upk3BuMHw@mail.gmail.com>
 <CAN-Kwu1NSspgtsn5mW+V_3NXcMeBxOMLV+G8d193AAUHsm+sFA@mail.gmail.com>
 <1537721859.3861.1.camel@daknuett.eu>
Message-ID: <2f8c0adf71a802f47cf94f95b842e6343dff02f7.camel@ronnypfannschmidt.de>

(re-sending since i used the wrong mail first)

I refuse since its a pain to sort out GDPR compliance when self-
hosting 
that way.

public is easy, public and law abiding is a pain.

-- Ronny

Am Sonntag, den 23.09.2018, 18:57 +0200 schrieb Daniel Kn?ttel:
> Am Sonntag, den 23.09.2018, 08:20 -0500 schrieb Ian Stapleton
> Cordasco:
> > It's also important to note that you need to have a Twitter account
> > to
> > vote, which will probably exclude a fair number of potential
> > voters.
> > 
> 
> This would exclude for instance me. If you send me the exact
> questions
> I can recreate the poll on my personal Nexcloud server so the poll is
> truly public.
> 
> By the way: I think 2.7 support should be dropped. 


From flub at devork.be  Sun Sep 23 14:47:14 2018
From: flub at devork.be (Floris Bruynooghe)
Date: Sun, 23 Sep 2018 20:47:14 +0200
Subject: [pytest-dev] keeping passwords out of code
In-Reply-To: <CAGf+Vg3rHkXuP0xTt3JzhfLbT9hvaQ1ZmPbfUYP55mgsk+febw@mail.gmail.com>
References: <CAGf+Vg3rHkXuP0xTt3JzhfLbT9hvaQ1ZmPbfUYP55mgsk+febw@mail.gmail.com>
Message-ID: <87pnx4m4p9.fsf@powell.devork.be>

Hi Derek,

On Sat 22 Sep 2018 at 09:19 -0700, Derek Sisson wrote:
> I currently use a local yaml file, with passwords keyed to account ids,
> along with a data model of users in the codebase keyed to the same IDs. My
> conftest queries the yaml file with the ids to grab the passwords, and it's
> set up to throw exceptions if there is anything out of sync between the
> data model and the yaml file data.
>
> Cumbersome, but works.... locally. I need to port the framework to Jenkins,
> so I need a better and secure system.
>
> Suggestions on better ways of managing passwords and secrets in a
> pytest/jenkins context?

This isn't really a pytest question to be fair.  It's just that you
happen to stumble into secrets management via testing, which is
certainly one common way of discovering this rabbit hole.

The simple version which is still somewhat sub-optimal is pass the
secrets via environment variables or something, for Jenkins specifically
you should probably look at it's Credentials Binding plugin or so.

The full-blow solution is to use something like vaultproject.io to
manage secrets.  Obviously this is a fair amount of work but you'll get
good secrets management at the end.


Cheers,
Floris

From opensource at ronnypfannschmidt.de  Mon Sep 24 09:28:47 2018
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Mon, 24 Sep 2018 15:28:47 +0200
Subject: [pytest-dev] branch proposals - python2 support and pytest 4.0 preps
Message-ID: <403bcddcef721e84f462ed90a9843177b9f3c4f8.camel@ronnypfannschmidt.de>

hi everyone,

in face of the pending larger changes for a pytest 4.0 removing various
things and for the support branching of python2 id like to propose 2
extra branches


a) maintenance-python2 : this will be the branch where bugfixes for the
last python2 suporting versions will happen

i intend to create it in line with the yet to be shaped plans for the
python2 support/maintenance branches once the poll results are reviwerd
and we have decided on a timeline to put into action

b) removals or breakage : this will be the branch where we merge
breaking changes in preparation of major releases

i'd like to get this one started soon and create according automation
to ensure we merge/move patches across bugfixes, features and the
removal/breakage branches in a timely manner

-- Ronny



From nicoddemus at gmail.com  Mon Sep 24 10:22:32 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 24 Sep 2018 11:22:32 -0300
Subject: [pytest-dev] branch proposals - python2 support and pytest 4.0
 preps
In-Reply-To: <403bcddcef721e84f462ed90a9843177b9f3c4f8.camel@ronnypfannschmidt.de>
References: <403bcddcef721e84f462ed90a9843177b9f3c4f8.camel@ronnypfannschmidt.de>
Message-ID: <CA+RQFfcLKH36Htq=UdJtarZus0NG7nirEJPyuKmKLonUmMzZpg@mail.gmail.com>

Hi Ronny,

On Mon, Sep 24, 2018 at 10:29 AM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

>
> a) maintenance-python2 : this will be the branch where bugfixes for the
> last python2 suporting versions will happen
>
> i intend to create it in line with the yet to be shaped plans for the
> python2 support/maintenance branches once the poll results are reviwerd
> and we have decided on a timeline to put into action
>

Sounds good.


> b) removals or breakage : this will be the branch where we merge
> breaking changes in preparation of major releases
>

Do we need this? I was thinking we would just remove the breaking changes
in the "features" branch after 4.0 is released (for 4.0 we will turn the
warnings into errors, removal will happen in 4.1).

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

From rpfannsc at redhat.com  Mon Sep 24 10:27:03 2018
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Mon, 24 Sep 2018 16:27:03 +0200
Subject: [pytest-dev] branch proposals - python2 support and pytest 4.0
 preps
In-Reply-To: <CA+RQFfcLKH36Htq=UdJtarZus0NG7nirEJPyuKmKLonUmMzZpg@mail.gmail.com>
References: <403bcddcef721e84f462ed90a9843177b9f3c4f8.camel@ronnypfannschmidt.de>
 <CA+RQFfcLKH36Htq=UdJtarZus0NG7nirEJPyuKmKLonUmMzZpg@mail.gmail.com>
Message-ID: <CAA10jzNvoBJQA8RK1bc0z3e72Okm7-d5hShGb1u8Ys5-YA3H2A@mail.gmail.com>

Am Mo., 24. Sep. 2018 um 16:22 Uhr schrieb Bruno Oliveira <
nicoddemus at gmail.com>:

> Hi Ronny,
>
> On Mon, Sep 24, 2018 at 10:29 AM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
>
>>
>> a) maintenance-python2 : this will be the branch where bugfixes for the
>> last python2 suporting versions will happen
>>
>> i intend to create it in line with the yet to be shaped plans for the
>> python2 support/maintenance branches once the poll results are reviwerd
>> and we have decided on a timeline to put into action
>>
>
> Sounds good.
>
>
>> b) removals or breakage : this will be the branch where we merge
>> breaking changes in preparation of major releases
>>
>
> Do we need this? I was thinking we would just remove the breaking changes
> in the "features" branch after 4.0 is released (for 4.0 we will turn the
> warnings into errors, removal will happen in 4.1).
>
> True, in that order its actually fine to sort out that way, my brain is a
bit hardwired to too strict semver

-- Ronny




> Cheers,
> Bruno
> _______________________________________________
> 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/20180924/b9cc89c9/attachment.html>

From nicholas+pytest at nicholaswilliams.net  Mon Sep 24 10:33:49 2018
From: nicholas+pytest at nicholaswilliams.net (Nicholas Williams)
Date: Mon, 24 Sep 2018 09:33:49 -0500
Subject: [pytest-dev] branch proposals - python2 support and pytest 4.0
 preps
In-Reply-To: <CAA10jzNvoBJQA8RK1bc0z3e72Okm7-d5hShGb1u8Ys5-YA3H2A@mail.gmail.com>
References: <403bcddcef721e84f462ed90a9843177b9f3c4f8.camel@ronnypfannschmidt.de>
 <CA+RQFfcLKH36Htq=UdJtarZus0NG7nirEJPyuKmKLonUmMzZpg@mail.gmail.com>
 <CAA10jzNvoBJQA8RK1bc0z3e72Okm7-d5hShGb1u8Ys5-YA3H2A@mail.gmail.com>
Message-ID: <CAGn4V3WiFVc48=9AWpKUWJzKXUij-peudtZmopgEcyKyYow_nw@mail.gmail.com>

Background question: Will PyTest 4.0 be removing support for Python 2? Or
am I misunderstanding this?

Thanks,

Nick


On Mon, Sep 24, 2018 at 9:27 AM, Ronny Pfannschmidt <rpfannsc at redhat.com>
wrote:

>
>
> Am Mo., 24. Sep. 2018 um 16:22 Uhr schrieb Bruno Oliveira <
> nicoddemus at gmail.com>:
>
>> Hi Ronny,
>>
>> On Mon, Sep 24, 2018 at 10:29 AM Ronny Pfannschmidt <
>> opensource at ronnypfannschmidt.de> wrote:
>>
>>>
>>> a) maintenance-python2 : this will be the branch where bugfixes for the
>>> last python2 suporting versions will happen
>>>
>>> i intend to create it in line with the yet to be shaped plans for the
>>> python2 support/maintenance branches once the poll results are reviwerd
>>> and we have decided on a timeline to put into action
>>>
>>
>> Sounds good.
>>
>>
>>> b) removals or breakage : this will be the branch where we merge
>>> breaking changes in preparation of major releases
>>>
>>
>> Do we need this? I was thinking we would just remove the breaking changes
>> in the "features" branch after 4.0 is released (for 4.0 we will turn the
>> warnings into errors, removal will happen in 4.1).
>>
>> True, in that order its actually fine to sort out that way, my brain is a
> bit hardwired to too strict semver
>
> -- Ronny
>
>
>
>
>> Cheers,
>> Bruno
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20180924/34dc23a3/attachment-0001.html>

From nicoddemus at gmail.com  Mon Sep 24 11:15:33 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 24 Sep 2018 12:15:33 -0300
Subject: [pytest-dev] branch proposals - python2 support and pytest 4.0
 preps
In-Reply-To: <CAGn4V3WiFVc48=9AWpKUWJzKXUij-peudtZmopgEcyKyYow_nw@mail.gmail.com>
References: <403bcddcef721e84f462ed90a9843177b9f3c4f8.camel@ronnypfannschmidt.de>
 <CA+RQFfcLKH36Htq=UdJtarZus0NG7nirEJPyuKmKLonUmMzZpg@mail.gmail.com>
 <CAA10jzNvoBJQA8RK1bc0z3e72Okm7-d5hShGb1u8Ys5-YA3H2A@mail.gmail.com>
 <CAGn4V3WiFVc48=9AWpKUWJzKXUij-peudtZmopgEcyKyYow_nw@mail.gmail.com>
Message-ID: <CA+RQFfdLoc8O7xcuSYjNgHGWAFjqYtdzky5FuyitTB=b0OoPbg@mail.gmail.com>

Hi Nicholas,

On Mon, Sep 24, 2018 at 11:33 AM Nicholas Williams <
nicholas+pytest at nicholaswilliams.net> wrote:

> Background question: Will PyTest 4.0 be removing support for Python 2? Or
> am I misunderstanding this?
>

No, Ronny's email address two topics: removal of currently deprecated
features (4.0 and 4.1) and dropping Python 2 support (no version defined
yet, but not 4.0, likely 5.0 or 6.0).

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

From nicholas+pytest at nicholaswilliams.net  Mon Sep 24 12:28:00 2018
From: nicholas+pytest at nicholaswilliams.net (Nicholas Williams)
Date: Mon, 24 Sep 2018 11:28:00 -0500
Subject: [pytest-dev] branch proposals - python2 support and pytest 4.0
 preps
In-Reply-To: <CA+RQFfdLoc8O7xcuSYjNgHGWAFjqYtdzky5FuyitTB=b0OoPbg@mail.gmail.com>
References: <403bcddcef721e84f462ed90a9843177b9f3c4f8.camel@ronnypfannschmidt.de>
 <CA+RQFfcLKH36Htq=UdJtarZus0NG7nirEJPyuKmKLonUmMzZpg@mail.gmail.com>
 <CAA10jzNvoBJQA8RK1bc0z3e72Okm7-d5hShGb1u8Ys5-YA3H2A@mail.gmail.com>
 <CAGn4V3WiFVc48=9AWpKUWJzKXUij-peudtZmopgEcyKyYow_nw@mail.gmail.com>
 <CA+RQFfdLoc8O7xcuSYjNgHGWAFjqYtdzky5FuyitTB=b0OoPbg@mail.gmail.com>
Message-ID: <CAGn4V3UFa+0b-CN8jBH8M6DZyFaiaD50vH_45PdACMSmU6778A@mail.gmail.com>

Gotcha. Thanks for clearing that up for me (and anyone else also confused)!

Nick

On Mon, Sep 24, 2018 at 10:15 AM, Bruno Oliveira <nicoddemus at gmail.com>
wrote:

> Hi Nicholas,
>
> On Mon, Sep 24, 2018 at 11:33 AM Nicholas Williams <nicholas+pytest@
> nicholaswilliams.net> wrote:
>
>> Background question: Will PyTest 4.0 be removing support for Python 2? Or
>> am I misunderstanding this?
>>
>
> No, Ronny's email address two topics: removal of currently deprecated
> features (4.0 and 4.1) and dropping Python 2 support (no version defined
> yet, but not 4.0, likely 5.0 or 6.0).
>
> Cheers,
> Bruno.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180924/3b228ca8/attachment.html>

From maiksensi at gmail.com  Mon Sep 24 13:52:14 2018
From: maiksensi at gmail.com (Maik Figura)
Date: Mon, 24 Sep 2018 19:52:14 +0200
Subject: [pytest-dev] Hacktoberfest - Beginner Issues
In-Reply-To: <CAPjwCjvzKcd3xCSFkaxaWF4hiqT50WR2WbTOqSQ3At04miEdpQ@mail.gmail.com>
References: <3b2a3db1-8be1-12e3-0e26-d90ce23d5f74@gmail.com>
 <CA+RQFffB77by8EZSJHVQfkAGqsb0Sx7yRYuxqMDU4R_o89KU4A@mail.gmail.com>
 <CAPjwCjtp8H+h9xFk6_-7KffJeeV457W63UnJ3kJ6uF5fwhLT6w@mail.gmail.com>
 <CAPjwCjvzKcd3xCSFkaxaWF4hiqT50WR2WbTOqSQ3At04miEdpQ@mail.gmail.com>
Message-ID: <CACzSEXGJRjYp92kQ9C5CGnoJOK3vrzbcSt+-zVHBsgG9O-aSmA@mail.gmail.com>

> The number of open issues is something that bugs me.
Dito. Because I think there are in fact issues that could be closed using
automated mechanisms.

> I would love to know how other projects which also face a large number of
issues deal with this.
I want to second Brianna's two topics:
> ... auto-close issues after a certain amount of time has passed without
activity.
To me that is a good mechanism, as long as it is automated and only happens
if we wait for feedback ("needs information" label for example can we
closed if we did not get a reply within X weeks).
This brings me to the second suggestion, which is a (bug) triaging guide.
> Writing up the existing process (eg intention of existing labels) may
help more people carry out bug triage
I think we would gain most by automating the process of closing tickets
where no follow up was given (from a users side). But this needs to be done
very carefully and in a documented way.
I am not sure there are more ways to help managing the immense amount of
issues (with the same amount of resources). Also, I dont think the bar to
submit a issue should be raised to ensure some sort of quality or else, but
instead it makes sense to automate the process of closing issues fast in a
documented and transparent way. Does pytest have some sort of process to
say "no" to requests (issue type doesnt really matter here if you ask me).
Is this even needed or do we already handle this in a good way?

One of my goals for the next Hackergarten Meetup in Stuttgart
(Hacktoberfestgarten in this case) will be to have a look at more projects
and see how they manage this and to come up with a proposal for pytest, so
we have something to discuss. If you have more input here, let me know so I
can work that in.

Best,
Maik.

On Sun, 9 Sep 2018 at 08:44, Brianna Laugher <brianna.laugher at gmail.com>
wrote:

> Some projects have a bug triaging guide, eg
> http://docs.hood.ie/en/latest/developers/TRIAGING.html . Writing up the
> existing process (eg intention of existing labels) may help more people
> carry out bug triage.
>
> On Sun, 9 Sep 2018 at 16:43, Brianna Laugher <brianna.laugher at gmail.com>
> wrote:
>
>> I have seen a lot of projects use something like
>> https://github.com/apps/stale to auto-close issues after a certain
>> amount of time has passed without activity.
>>
>> On Fri, 7 Sep 2018 at 04:21, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>>
>>>
>>> On Thu, Sep 6, 2018 at 2:26 PM Maik Figura <maiksensi at gmail.com> wrote:
>>>
>>>> Hey everyone,
>>>>
>>>> I noticed that the issue tracker almost hit 500 issues. Would it be good
>>>> to discuss how to handle issues in general (follow ups, etc) and on how
>>>> to maybe reduce the amount of outdated issues (I am not even sure there
>>>> are outdated ones...). Do we maybe have examples how other projects do
>>>> this? Or maybe this was already discussed and I just missed it?
>>>>
>>>>
>>> Hi Maik,
>>>
>>> (I'm adressing the contents of the email, not the title :))
>>>
>>> The number of open issues is something that bugs me. One of the reasons
>>> that labels like "question" and "needs information" were created was that
>>> we could periodically go over issues marked with them and close if they
>>> have been inactive after some time, but this is something that has to be
>>> done regularly.
>>>
>>> I would love to know how other projects which also face a large number
>>> of issues deal with this.
>>>
>>> Cheers,
>>> Bruno.
>>> _______________________________________________
>>> pytest-dev mailing list
>>> pytest-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>>
>>
>> --
>> They've just been waiting in a mountain for the right moment:
>> http://modernthings.org/
>>
>
>
> --
> They've just been waiting in a mountain for the right moment:
> http://modernthings.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180924/78263d34/attachment.html>

From dhunt at mozilla.com  Wed Sep 26 04:57:51 2018
From: dhunt at mozilla.com (Dave Hunt)
Date: Wed, 26 Sep 2018 09:57:51 +0100
Subject: [pytest-dev] keeping passwords out of code
In-Reply-To: <87pnx4m4p9.fsf@powell.devork.be>
References: <CAGf+Vg3rHkXuP0xTt3JzhfLbT9hvaQ1ZmPbfUYP55mgsk+febw@mail.gmail.com>
 <87pnx4m4p9.fsf@powell.devork.be>
Message-ID: <1464D671-9274-4511-A2FF-8B7A077E5A0D@mozilla.com>

This is what I originally developed pytest-variables for (https://pypi.org/project/pytest-variables/ <https://pypi.org/project/pytest-variables/>). Maybe you?ll find that useful, but it sounds like you already have a similar solution. For Jenkins, we use the credentials plugin to store the variables files, and then reference them from the jobs via environment variables. See https://github.com/mozilla/mozillians-tests/blob/master/Jenkinsfile#L40 <https://github.com/mozilla/mozillians-tests/blob/master/Jenkinsfile#L40> and https://github.com/mozilla/mozillians-tests/blob/master/Jenkinsfile#L53 <https://github.com/mozilla/mozillians-tests/blob/master/Jenkinsfile#L53> for an example of where we use this in a Jenkins declarative pipeline.

> On 23 Sep 2018, at 19:47, Floris Bruynooghe <flub at devork.be> wrote:
> 
> Hi Derek,
> 
> On Sat 22 Sep 2018 at 09:19 -0700, Derek Sisson wrote:
>> I currently use a local yaml file, with passwords keyed to account ids,
>> along with a data model of users in the codebase keyed to the same IDs. My
>> conftest queries the yaml file with the ids to grab the passwords, and it's
>> set up to throw exceptions if there is anything out of sync between the
>> data model and the yaml file data.
>> 
>> Cumbersome, but works.... locally. I need to port the framework to Jenkins,
>> so I need a better and secure system.
>> 
>> Suggestions on better ways of managing passwords and secrets in a
>> pytest/jenkins context?
> 
> This isn't really a pytest question to be fair.  It's just that you
> happen to stumble into secrets management via testing, which is
> certainly one common way of discovering this rabbit hole.
> 
> The simple version which is still somewhat sub-optimal is pass the
> secrets via environment variables or something, for Jenkins specifically
> you should probably look at it's Credentials Binding plugin or so.
> 
> The full-blow solution is to use something like vaultproject.io to
> manage secrets.  Obviously this is a fair amount of work but you'll get
> good secrets management at the end.
> 
> 
> Cheers,
> 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/20180926/037d2f75/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180926/037d2f75/attachment.sig>