From markus at unterwaditzer.net  Wed Oct  2 10:26:34 2019
From: markus at unterwaditzer.net (Markus Unterwaditzer)
Date: Wed, 2 Oct 2019 16:26:34 +0200
Subject: [pytest-dev] Maintenance of pytest-forked
Message-ID: <CCF85B07-4816-4812-A306-5A9D0F554381@unterwaditzer.net>

Hi,

I use pytest-forked and would like to add a few more features to it revolving around gradually opting in or out of forking before testing. Since it it unmaintained I volunteer to help out with that. What are your thoughts?

Thanks,
Markus (untitaker on github)

From rpfannsc at redhat.com  Wed Oct  2 11:41:12 2019
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Wed, 2 Oct 2019 17:41:12 +0200
Subject: [pytest-dev] Maintenance of pytest-forked
In-Reply-To: <CCF85B07-4816-4812-A306-5A9D0F554381@unterwaditzer.net>
References: <CCF85B07-4816-4812-A306-5A9D0F554381@unterwaditzer.net>
Message-ID: <CAA10jzPJ7RLh_hP4ofcW707vNi5jimMh_B=qvaxCLeWVvCjyFA@mail.gmail.com>

+1

On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer <markus at unterwaditzer.net>
wrote:

> Hi,
>
> I use pytest-forked and would like to add a few more features to it
> revolving around gradually opting in or out of forking before testing.
> Since it it unmaintained I volunteer to help out with that. What are your
> thoughts?
>
> Thanks,
> Markus (untitaker on github)
> _______________________________________________
> 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/20191002/6ac00424/attachment.html>

From flub at devork.be  Wed Oct  2 13:58:23 2019
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 02 Oct 2019 19:58:23 +0200
Subject: [pytest-dev] Maintenance of pytest-forked
In-Reply-To: <CAA10jzPJ7RLh_hP4ofcW707vNi5jimMh_B=qvaxCLeWVvCjyFA@mail.gmail.com>
References: <CCF85B07-4816-4812-A306-5A9D0F554381@unterwaditzer.net>
 <CAA10jzPJ7RLh_hP4ofcW707vNi5jimMh_B=qvaxCLeWVvCjyFA@mail.gmail.com>
Message-ID: <87r23vt4g0.fsf@powell.devork.be>

I've created a pytest-forked-developers team, invited untitaker and gave
the team write permissions on pytest-forked.  I'll ask for forgiveness
and undo if that was undesired ;)

Cheers,
Floris


On Wed 02 Oct 2019 at 17:41 +0200, Ronny Pfannschmidt wrote:

> +1
>
> On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer <markus at unterwaditzer.net>
> wrote:
>
>> Hi,
>>
>> I use pytest-forked and would like to add a few more features to it
>> revolving around gradually opting in or out of forking before testing.
>> Since it it unmaintained I volunteer to help out with that. What are your
>> thoughts?
>>
>> Thanks,
>> Markus (untitaker on github)
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>

From opensource at ronnypfannschmidt.de  Wed Oct  2 15:15:16 2019
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 02 Oct 2019 21:15:16 +0200
Subject: [pytest-dev] Maintenance of pytest-forked
In-Reply-To: <87r23vt4g0.fsf@powell.devork.be>
References: <CCF85B07-4816-4812-A306-5A9D0F554381@unterwaditzer.net>
 <CAA10jzPJ7RLh_hP4ofcW707vNi5jimMh_B=qvaxCLeWVvCjyFA@mail.gmail.com>
 <87r23vt4g0.fsf@powell.devork.be>
Message-ID: <A15D98A3-5AD8-442A-B0AB-1964379C091E@ronnypfannschmidt.de>

Fabulous, thanks

For some tasks it's a joy if they are already done when you get to them

--Ronny 

Am 2. Oktober 2019 19:58:23 MESZ schrieb Floris Bruynooghe <flub at devork.be>:
>I've created a pytest-forked-developers team, invited untitaker and
>gave
>the team write permissions on pytest-forked.  I'll ask for forgiveness
>and undo if that was undesired ;)
>
>Cheers,
>Floris
>
>
>On Wed 02 Oct 2019 at 17:41 +0200, Ronny Pfannschmidt wrote:
>
>> +1
>>
>> On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer
><markus at unterwaditzer.net>
>> wrote:
>>
>>> Hi,
>>>
>>> I use pytest-forked and would like to add a few more features to it
>>> revolving around gradually opting in or out of forking before
>testing.
>>> Since it it unmaintained I volunteer to help out with that. What are
>your
>>> thoughts?
>>>
>>> Thanks,
>>> Markus (untitaker on github)
>>> _______________________________________________
>>> 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/20191002/a399565f/attachment.html>

From opensource at ronnypfannschmidt.de  Wed Oct  2 15:15:16 2019
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 02 Oct 2019 21:15:16 +0200
Subject: [pytest-dev] Maintenance of pytest-forked
In-Reply-To: <87r23vt4g0.fsf@powell.devork.be>
References: <CCF85B07-4816-4812-A306-5A9D0F554381@unterwaditzer.net>
 <CAA10jzPJ7RLh_hP4ofcW707vNi5jimMh_B=qvaxCLeWVvCjyFA@mail.gmail.com>
 <87r23vt4g0.fsf@powell.devork.be>
Message-ID: <A15D98A3-5AD8-442A-B0AB-1964379C091E@ronnypfannschmidt.de>

Fabulous, thanks

For some tasks it's a joy if they are already done when you get to them

--Ronny 

Am 2. Oktober 2019 19:58:23 MESZ schrieb Floris Bruynooghe <flub at devork.be>:
>I've created a pytest-forked-developers team, invited untitaker and
>gave
>the team write permissions on pytest-forked.  I'll ask for forgiveness
>and undo if that was undesired ;)
>
>Cheers,
>Floris
>
>
>On Wed 02 Oct 2019 at 17:41 +0200, Ronny Pfannschmidt wrote:
>
>> +1
>>
>> On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer
><markus at unterwaditzer.net>
>> wrote:
>>
>>> Hi,
>>>
>>> I use pytest-forked and would like to add a few more features to it
>>> revolving around gradually opting in or out of forking before
>testing.
>>> Since it it unmaintained I volunteer to help out with that. What are
>your
>>> thoughts?
>>>
>>> Thanks,
>>> Markus (untitaker on github)
>>> _______________________________________________
>>> 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/20191002/a399565f/attachment-0001.html>

From nicoddemus at gmail.com  Sun Oct  6 11:56:41 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sun, 6 Oct 2019 12:56:41 -0300
Subject: [pytest-dev] pytest 5.2.1
Message-ID: <CA+RQFffF8OsTUvdU0CG_teqmVpEMoSi6uTDYeyubKcVrafezpg@mail.gmail.com>

pytest 5.2.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:

* Anthony Sottile
* Bruno Oliveira
* Florian Bruhin
* Hynek Schlawack
* Kevin J. Foley
* tadashigaki


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

From frank.tobia at gmail.com  Tue Oct  8 16:44:13 2019
From: frank.tobia at gmail.com (Frank Tobia)
Date: Tue, 8 Oct 2019 16:44:13 -0400
Subject: [pytest-dev] transferring ownership of pytest-ordering
Message-ID: <CAK2WskDVU5ex0Vre3kt+NCG+tZP_80ecrr5BLtNTn9kcX-_pQQ@mail.gmail.com>

Hi there,

I wrote pytest-ordering but I haven't been doing a great job of maintaining
it. I'd like to transfer ownership to the pytest-dev group if that's
amenable. I think all the requirements for transferring are fulfilled but
I'd appreciate calling out if I missed something (
https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev
).

Here's the repo: https://github.com/ftobia/pytest-ordering

Thanks in advance.

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

From nicoddemus at gmail.com  Tue Oct  8 18:41:00 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 8 Oct 2019 19:41:00 -0300
Subject: [pytest-dev] transferring ownership of pytest-ordering
In-Reply-To: <CAK2WskDVU5ex0Vre3kt+NCG+tZP_80ecrr5BLtNTn9kcX-_pQQ@mail.gmail.com>
References: <CAK2WskDVU5ex0Vre3kt+NCG+tZP_80ecrr5BLtNTn9kcX-_pQQ@mail.gmail.com>
Message-ID: <CA+RQFfdsSeBhikcUtE+iwu=1pDhbiweAQk9BTuCUJiMb8kU+9A@mail.gmail.com>

Hi Frank,

Thanks for the interest in transferring pytest-ordering over to pytest-dev!

Keep in mind though that the intent of moving plugins over to the
pytest-dev organization is not to transfer maintenance responsibilities,
but a way for plugins to get more visibility and prevent "plugin
abandonment", where the sole maintainer is no longer responsive and the
plugin is effectively dead because nobody else has commit/publishing
rights.

Having said that, before moving the plugin over to pytest-dev (which it
would be welcome otherwise!) I suggest to find some co-maintainers first,
so when the plugin gets transferred, it will have someone to fix the
eventual bug or merge a PR.

People have had great success getting interested co-maintainers by posting
to mailing lists and Twitter, as well as asking if any of the previous
contributors would be interested in being co-maintainers; it might be
surprising how sometimes people step in.

Let me know if you have any questions!

Cheers,
Bruno



On Tue, Oct 8, 2019 at 5:45 PM Frank Tobia <frank.tobia at gmail.com> wrote:

> Hi there,
>
> I wrote pytest-ordering but I haven't been doing a great job of
> maintaining it. I'd like to transfer ownership to the pytest-dev group if
> that's amenable. I think all the requirements for transferring are
> fulfilled but I'd appreciate calling out if I missed something (
> https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev
> ).
>
> Here's the repo: https://github.com/ftobia/pytest-ordering
>
> Thanks in advance.
>
> -Frank
> _______________________________________________
> 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/20191008/517a5080/attachment.html>

From frank.tobia at gmail.com  Wed Oct  9 10:12:38 2019
From: frank.tobia at gmail.com (Frank Tobia)
Date: Wed, 9 Oct 2019 10:12:38 -0400
Subject: [pytest-dev] transferring ownership of pytest-ordering
In-Reply-To: <CA+RQFfdsSeBhikcUtE+iwu=1pDhbiweAQk9BTuCUJiMb8kU+9A@mail.gmail.com>
References: <CAK2WskDVU5ex0Vre3kt+NCG+tZP_80ecrr5BLtNTn9kcX-_pQQ@mail.gmail.com>
 <CA+RQFfdsSeBhikcUtE+iwu=1pDhbiweAQk9BTuCUJiMb8kU+9A@mail.gmail.com>
Message-ID: <CAK2WskDxcRfe1mVi-jwTpUPFEHeJdR_KsiUqHMXmCscath0LiA@mail.gmail.com>

Good point re: transfer ownership != maintenance handoff. I'll try to drum
up some number of maintainers.
At least one potential volunteer has reached out to me so far, so thanks
for the tweet :)

-Frank

On Tue, Oct 8, 2019 at 6:41 PM Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi Frank,
>
> Thanks for the interest in transferring pytest-ordering over to pytest-dev!
>
> Keep in mind though that the intent of moving plugins over to the
> pytest-dev organization is not to transfer maintenance responsibilities,
> but a way for plugins to get more visibility and prevent "plugin
> abandonment", where the sole maintainer is no longer responsive and the
> plugin is effectively dead because nobody else has commit/publishing
> rights.
>
> Having said that, before moving the plugin over to pytest-dev (which it
> would be welcome otherwise!) I suggest to find some co-maintainers first,
> so when the plugin gets transferred, it will have someone to fix the
> eventual bug or merge a PR.
>
> People have had great success getting interested co-maintainers by posting
> to mailing lists and Twitter, as well as asking if any of the previous
> contributors would be interested in being co-maintainers; it might be
> surprising how sometimes people step in.
>
> Let me know if you have any questions!
>
> Cheers,
> Bruno
>
>
>
> On Tue, Oct 8, 2019 at 5:45 PM Frank Tobia <frank.tobia at gmail.com> wrote:
>
>> Hi there,
>>
>> I wrote pytest-ordering but I haven't been doing a great job of
>> maintaining it. I'd like to transfer ownership to the pytest-dev group if
>> that's amenable. I think all the requirements for transferring are
>> fulfilled but I'd appreciate calling out if I missed something (
>> https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev
>> ).
>>
>> Here's the repo: https://github.com/ftobia/pytest-ordering
>>
>> Thanks in advance.
>>
>> -Frank
>> _______________________________________________
>> 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/20191009/ca11f0ff/attachment.html>

From nicoddemus at gmail.com  Wed Oct  9 11:35:34 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 9 Oct 2019 12:35:34 -0300
Subject: [pytest-dev] transferring ownership of pytest-ordering
In-Reply-To: <CAK2WskDxcRfe1mVi-jwTpUPFEHeJdR_KsiUqHMXmCscath0LiA@mail.gmail.com>
References: <CAK2WskDVU5ex0Vre3kt+NCG+tZP_80ecrr5BLtNTn9kcX-_pQQ@mail.gmail.com>
 <CA+RQFfdsSeBhikcUtE+iwu=1pDhbiweAQk9BTuCUJiMb8kU+9A@mail.gmail.com>
 <CAK2WskDxcRfe1mVi-jwTpUPFEHeJdR_KsiUqHMXmCscath0LiA@mail.gmail.com>
Message-ID: <CA+RQFffU7DmRcyHKoia_LBeU1sJq7U1EX8qc9fAREzPMX3DTog@mail.gmail.com>

Good news Frank,

Once we have one or more active maintainers, we will be happy to transfer
the plugin to pytest-dev!

[]s

On Wed, Oct 9, 2019 at 11:13 AM Frank Tobia <frank.tobia at gmail.com> wrote:

> Good point re: transfer ownership != maintenance handoff. I'll try to drum
> up some number of maintainers.
> At least one potential volunteer has reached out to me so far, so thanks
> for the tweet :)
>
> -Frank
>
> On Tue, Oct 8, 2019 at 6:41 PM Bruno Oliveira <nicoddemus at gmail.com>
> wrote:
>
>> Hi Frank,
>>
>> Thanks for the interest in transferring pytest-ordering over to
>> pytest-dev!
>>
>> Keep in mind though that the intent of moving plugins over to the
>> pytest-dev organization is not to transfer maintenance responsibilities,
>> but a way for plugins to get more visibility and prevent "plugin
>> abandonment", where the sole maintainer is no longer responsive and the
>> plugin is effectively dead because nobody else has commit/publishing
>> rights.
>>
>> Having said that, before moving the plugin over to pytest-dev (which it
>> would be welcome otherwise!) I suggest to find some co-maintainers first,
>> so when the plugin gets transferred, it will have someone to fix the
>> eventual bug or merge a PR.
>>
>> People have had great success getting interested co-maintainers by
>> posting to mailing lists and Twitter, as well as asking if any of the
>> previous contributors would be interested in being co-maintainers; it might
>> be surprising how sometimes people step in.
>>
>> Let me know if you have any questions!
>>
>> Cheers,
>> Bruno
>>
>>
>>
>> On Tue, Oct 8, 2019 at 5:45 PM Frank Tobia <frank.tobia at gmail.com> wrote:
>>
>>> Hi there,
>>>
>>> I wrote pytest-ordering but I haven't been doing a great job of
>>> maintaining it. I'd like to transfer ownership to the pytest-dev group if
>>> that's amenable. I think all the requirements for transferring are
>>> fulfilled but I'd appreciate calling out if I missed something (
>>> https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting-plugins-to-pytest-dev
>>> ).
>>>
>>> Here's the repo: https://github.com/ftobia/pytest-ordering
>>>
>>> Thanks in advance.
>>>
>>> -Frank
>>> _______________________________________________
>>> 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/20191009/0686fa0a/attachment-0001.html>

From nicoddemus at gmail.com  Sun Oct 13 11:01:19 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Sun, 13 Oct 2019 12:01:19 -0300
Subject: [pytest-dev] pytest 4.6.6
Message-ID: <CA+RQFfdR+2XK+qC0yX=Mh0qZtC60kZGWH9WsL8ak9B2k8O+L1w@mail.gmail.com>

pytest 4.6.6 has just been released to PyPI.

Backport of bug fixes for the last version to support Python 2.7 and 3.4,
being a drop-in replacement. To upgrade::

  pip install --upgrade pytest

The full changelog is available at
https://docs.pytest.org/en/4.6-maintenance/changelog.html

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

* Anthony Sottile
* Bruno Oliveira
* Michael Goerz


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

From rpfannsc at redhat.com  Tue Oct 15 09:03:11 2019
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Tue, 15 Oct 2019 15:03:11 +0200
Subject: [pytest-dev] [proposal] global and per item data stashes
Message-ID: <CAA10jzPDuu2bZwKYzaOKJneu0TAV7YT=-0BO=X9mYz19HUR4OA@mail.gmail.com>

Problem: for the storage of helper objects that either tackle certain
global tracking details or that track information over the testprotocol
lifecycle of test items, we use monkeypatchs and generally just munge
around in either the pytest config object or item objects.

I would like to propose a new API putting those details into consideration.



  config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
pytest session lifetime
  item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
run-test protocol cycle of item

Each stash  would be a context manager and construction would get access to
both item and config.

This would for example enable to express the junit xml logger object and
configuration as

`config.get_stash(__name__, JunitXMlTracker)`

Just as  it would allow other plugin to store node lifecycle related
details within the node using a well known mechanism

Incidentally this would also be a good fit for the fixture system and
setup-state in general to store information.

The basic assumption being that only the stashes of the items that are
currently active are valid, and other stashes are torn down,
then fixtures as well as the fixture request would nicely fit that storage
mechanism, and would also generalize across the node tree from session down
to individual items.

(considering the layout, it might be sensible to even replace
config.get_stash with something
like session.get_stash)

The idea is still rather fuzzy in my head and i would love to di either
text based brainstorming on it, or a actual video call.

-- Ronny

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/20191015/41a50bcc/attachment.html>

From nicoddemus at gmail.com  Tue Oct 15 19:23:28 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 15 Oct 2019 20:23:28 -0300
Subject: [pytest-dev] [proposal] global and per item data stashes
In-Reply-To: <CAA10jzPDuu2bZwKYzaOKJneu0TAV7YT=-0BO=X9mYz19HUR4OA@mail.gmail.com>
References: <CAA10jzPDuu2bZwKYzaOKJneu0TAV7YT=-0BO=X9mYz19HUR4OA@mail.gmail.com>
Message-ID: <CA+RQFffEnt=XouphLMKq232oYOH4LZcdZkmw_vuHtaB4HWgYqw@mail.gmail.com>

Hi Ronny,

As you have shared this before in chat, at first glance it sounds like a
good idea!

Some questions that we can probably elaborate on once we have something
more concrete to discuss:

1. You say "each stash  would be a context manager", but it is not clear to
me how this would work in practice, as most uses today that need to
decorate the object need to do it across multiple function calls (for
example, creating an object in `pytest_configure` and storing it in a
stash, only to retrieve the data later in another hook). Can you provide
examples to clarify this?

2. If we are to use the "stash" for fixtures, we need  a way to specify
stashes whose other lifetimes than function and session, like class, module
and package. Any idea how this would look like?

Other than that, where do you want to go from here? Keep the discussion
here in the mailing list, move it to the issue tracker, or somewhere else?

Cheers,
Bruno.


On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <rpfannsc at redhat.com>
wrote:

> Problem: for the storage of helper objects that either tackle certain
> global tracking details or that track information over the testprotocol
> lifecycle of test items, we use monkeypatchs and generally just munge
> around in either the pytest config object or item objects.
>
> I would like to propose a new API putting those details into consideration.
>
>
>
>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
> pytest session lifetime
>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
> run-test protocol cycle of item
>
> Each stash  would be a context manager and construction would get access
> to both item and config.
>
> This would for example enable to express the junit xml logger object and
> configuration as
>
> `config.get_stash(__name__, JunitXMlTracker)`
>
> Just as  it would allow other plugin to store node lifecycle related
> details within the node using a well known mechanism
>
> Incidentally this would also be a good fit for the fixture system and
> setup-state in general to store information.
>
> The basic assumption being that only the stashes of the items that are
> currently active are valid, and other stashes are torn down,
> then fixtures as well as the fixture request would nicely fit that storage
> mechanism, and would also generalize across the node tree from session down
> to individual items.
>
> (considering the layout, it might be sensible to even replace
> config.get_stash with something
> like session.get_stash)
>
> The idea is still rather fuzzy in my head and i would love to di either
> text based brainstorming on it, or a actual video call.
>
> -- Ronny
>
> 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/20191015/c0c44a53/attachment.html>

From rpfannsc at redhat.com  Wed Oct 16 03:45:11 2019
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Wed, 16 Oct 2019 09:45:11 +0200
Subject: [pytest-dev] [proposal] global and per item data stashes
In-Reply-To: <CA+RQFffEnt=XouphLMKq232oYOH4LZcdZkmw_vuHtaB4HWgYqw@mail.gmail.com>
References: <CAA10jzPDuu2bZwKYzaOKJneu0TAV7YT=-0BO=X9mYz19HUR4OA@mail.gmail.com>
 <CA+RQFffEnt=XouphLMKq232oYOH4LZcdZkmw_vuHtaB4HWgYqw@mail.gmail.com>
Message-ID: <CAA10jzO6_Ez9RqZGUFWBgHfUeG0Yz+zu5Ttd3ap-RQXNgQ8L6A@mail.gmail.com>

On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi Ronny,
>
> As you have shared this before in chat, at first glance it sounds like a
> good idea!
>
> Some questions that we can probably elaborate on once we have something
> more concrete to discuss:
>
> 1. You say "each stash  would be a context manager", but it is not clear
> to me how this would work in practice, as most uses today that need to
> decorate the object need to do it across multiple function calls (for
> example, creating an object in `pytest_configure` and storing it in a
> stash, only to retrieve the data later in another hook). Can you provide
> examples to clarify this?
>
the value returned from get_stash would be the value the entering of the
context manager yielded
this also means that for a item or a class there may be multiple stashes
over a test-run, as each stash would have been entered in a different
lifecycles



>
> 2. If we are to use the "stash" for fixtures, we need  a way to specify
> stashes whose other lifetimes than function and session, like class, module
> and package. Any idea how this would look like?
>
those stashes would just be modelled on the belonging nodes, so fixtures
for session, stashed on session, fixtures for class, stashed on class and
so on



>
> Other than that, where do you want to go from here? Keep the discussion
> here in the mailing list, move it to the issue tracker, or somewhere else?
>
i'd like some more iteration on the basics, then perhaps a quick video
conference to solidify the thinking,
then set up a github project.

-- Ronny



>
> Cheers,
> Bruno.
>
>
> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <rpfannsc at redhat.com>
> wrote:
>
>> Problem: for the storage of helper objects that either tackle certain
>> global tracking details or that track information over the testprotocol
>> lifecycle of test items, we use monkeypatchs and generally just munge
>> around in either the pytest config object or item objects.
>>
>> I would like to propose a new API putting those details into
>> consideration.
>>
>>
>>
>>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
>> pytest session lifetime
>>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
>> run-test protocol cycle of item
>>
>> Each stash  would be a context manager and construction would get access
>> to both item and config.
>>
>> This would for example enable to express the junit xml logger object and
>> configuration as
>>
>> `config.get_stash(__name__, JunitXMlTracker)`
>>
>> Just as  it would allow other plugin to store node lifecycle related
>> details within the node using a well known mechanism
>>
>> Incidentally this would also be a good fit for the fixture system and
>> setup-state in general to store information.
>>
>> The basic assumption being that only the stashes of the items that are
>> currently active are valid, and other stashes are torn down,
>> then fixtures as well as the fixture request would nicely fit that
>> storage mechanism, and would also generalize across the node tree from
>> session down to individual items.
>>
>> (considering the layout, it might be sensible to even replace
>> config.get_stash with something
>> like session.get_stash)
>>
>> The idea is still rather fuzzy in my head and i would love to di either
>> text based brainstorming on it, or a actual video call.
>>
>> -- Ronny
>>
>> 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
>>
>

-- 

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/20191016/747dcb46/attachment-0001.html>

From rpfannsc at redhat.com  Wed Oct 16 09:42:01 2019
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Wed, 16 Oct 2019 15:42:01 +0200
Subject: [pytest-dev] [proposal] global and per item data stashes
In-Reply-To: <CAA10jzO6_Ez9RqZGUFWBgHfUeG0Yz+zu5Ttd3ap-RQXNgQ8L6A@mail.gmail.com>
References: <CAA10jzPDuu2bZwKYzaOKJneu0TAV7YT=-0BO=X9mYz19HUR4OA@mail.gmail.com>
 <CA+RQFffEnt=XouphLMKq232oYOH4LZcdZkmw_vuHtaB4HWgYqw@mail.gmail.com>
 <CAA10jzO6_Ez9RqZGUFWBgHfUeG0Yz+zu5Ttd3ap-RQXNgQ8L6A@mail.gmail.com>
Message-ID: <CAA10jzOff1UVNZMUhpKPzCK1kbZR+Yji_YsCs3HSk6-ecYzOVQ@mail.gmail.com>

a little side note as  i was  just having a little discussion about this
with a native speaker,
the word stash isn`t quite fitting the concept - the name scoped_storage
came to mind,
we might need to iterate on the concept name a bit to get to something that
makes deeper sense

- Ronny

On Wed, 16 Oct 2019 at 09:45, Ronny Pfannschmidt <rpfannsc at redhat.com>
wrote:

>
>
> On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>
>> Hi Ronny,
>>
>> As you have shared this before in chat, at first glance it sounds like a
>> good idea!
>>
>> Some questions that we can probably elaborate on once we have something
>> more concrete to discuss:
>>
>> 1. You say "each stash  would be a context manager", but it is not clear
>> to me how this would work in practice, as most uses today that need to
>> decorate the object need to do it across multiple function calls (for
>> example, creating an object in `pytest_configure` and storing it in a
>> stash, only to retrieve the data later in another hook). Can you provide
>> examples to clarify this?
>>
> the value returned from get_stash would be the value the entering of the
> context manager yielded
> this also means that for a item or a class there may be multiple stashes
> over a test-run, as each stash would have been entered in a different
> lifecycles
>
>
>
>>
>> 2. If we are to use the "stash" for fixtures, we need  a way to specify
>> stashes whose other lifetimes than function and session, like class, module
>> and package. Any idea how this would look like?
>>
> those stashes would just be modelled on the belonging nodes, so fixtures
> for session, stashed on session, fixtures for class, stashed on class and
> so on
>
>
>
>>
>> Other than that, where do you want to go from here? Keep the discussion
>> here in the mailing list, move it to the issue tracker, or somewhere else?
>>
> i'd like some more iteration on the basics, then perhaps a quick video
> conference to solidify the thinking,
> then set up a github project.
>
> -- Ronny
>
>
>
>>
>> Cheers,
>> Bruno.
>>
>>
>> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <rpfannsc at redhat.com>
>> wrote:
>>
>>> Problem: for the storage of helper objects that either tackle certain
>>> global tracking details or that track information over the testprotocol
>>> lifecycle of test items, we use monkeypatchs and generally just munge
>>> around in either the pytest config object or item objects.
>>>
>>> I would like to propose a new API putting those details into
>>> consideration.
>>>
>>>
>>>
>>>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
>>> pytest session lifetime
>>>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
>>> run-test protocol cycle of item
>>>
>>> Each stash  would be a context manager and construction would get access
>>> to both item and config.
>>>
>>> This would for example enable to express the junit xml logger object and
>>> configuration as
>>>
>>> `config.get_stash(__name__, JunitXMlTracker)`
>>>
>>> Just as  it would allow other plugin to store node lifecycle related
>>> details within the node using a well known mechanism
>>>
>>> Incidentally this would also be a good fit for the fixture system and
>>> setup-state in general to store information.
>>>
>>> The basic assumption being that only the stashes of the items that are
>>> currently active are valid, and other stashes are torn down,
>>> then fixtures as well as the fixture request would nicely fit that
>>> storage mechanism, and would also generalize across the node tree from
>>> session down to individual items.
>>>
>>> (considering the layout, it might be sensible to even replace
>>> config.get_stash with something
>>> like session.get_stash)
>>>
>>> The idea is still rather fuzzy in my head and i would love to di either
>>> text based brainstorming on it, or a actual video call.
>>>
>>> -- Ronny
>>>
>>> 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
>>>
>>
>
> --
>
> 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
>
>

-- 

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/20191016/da0c536e/attachment.html>

From victor.maryama at gmail.com  Wed Oct 16 10:26:41 2019
From: victor.maryama at gmail.com (Victor Maryama)
Date: Wed, 16 Oct 2019 16:26:41 +0200
Subject: [pytest-dev] [proposal] global and per item data stashes
In-Reply-To: <CAA10jzOff1UVNZMUhpKPzCK1kbZR+Yji_YsCs3HSk6-ecYzOVQ@mail.gmail.com>
References: <CAA10jzPDuu2bZwKYzaOKJneu0TAV7YT=-0BO=X9mYz19HUR4OA@mail.gmail.com>
 <CA+RQFffEnt=XouphLMKq232oYOH4LZcdZkmw_vuHtaB4HWgYqw@mail.gmail.com>
 <CAA10jzO6_Ez9RqZGUFWBgHfUeG0Yz+zu5Ttd3ap-RQXNgQ8L6A@mail.gmail.com>
 <CAA10jzOff1UVNZMUhpKPzCK1kbZR+Yji_YsCs3HSk6-ecYzOVQ@mail.gmail.com>
Message-ID: <CAN0FtzO1bBnyygqbQ7CXmTqWecywNUUvKq708yovPZLgezD2Tw@mail.gmail.com>

Hi guys! I am no expert, but maybe is this something that could replace or
intersect with the functionality provided by
https://smarie.github.io/python-pytest-harvest/ (fixture_store and
results_bag fixtures)? And maybe the code that is saving fixture and test
context information like in allure-pytest.

Although probably it would require the stashes not to be torn down, in
opposition to the original Ronny's idea.

Le mer. 16 oct. 2019 ? 15:42, Ronny Pfannschmidt <rpfannsc at redhat.com> a
?crit :

> a little side note as  i was  just having a little discussion about this
> with a native speaker,
> the word stash isn`t quite fitting the concept - the name scoped_storage
> came to mind,
> we might need to iterate on the concept name a bit to get to something
> that makes deeper sense
>
> - Ronny
>
> On Wed, 16 Oct 2019 at 09:45, Ronny Pfannschmidt <rpfannsc at redhat.com>
> wrote:
>
>>
>>
>> On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <nicoddemus at gmail.com>
>> wrote:
>>
>>> Hi Ronny,
>>>
>>> As you have shared this before in chat, at first glance it sounds like a
>>> good idea!
>>>
>>> Some questions that we can probably elaborate on once we have something
>>> more concrete to discuss:
>>>
>>> 1. You say "each stash  would be a context manager", but it is not clear
>>> to me how this would work in practice, as most uses today that need to
>>> decorate the object need to do it across multiple function calls (for
>>> example, creating an object in `pytest_configure` and storing it in a
>>> stash, only to retrieve the data later in another hook). Can you provide
>>> examples to clarify this?
>>>
>> the value returned from get_stash would be the value the entering of the
>> context manager yielded
>> this also means that for a item or a class there may be multiple stashes
>> over a test-run, as each stash would have been entered in a different
>> lifecycles
>>
>>
>>
>>>
>>> 2. If we are to use the "stash" for fixtures, we need  a way to specify
>>> stashes whose other lifetimes than function and session, like class, module
>>> and package. Any idea how this would look like?
>>>
>> those stashes would just be modelled on the belonging nodes, so fixtures
>> for session, stashed on session, fixtures for class, stashed on class and
>> so on
>>
>>
>>
>>>
>>> Other than that, where do you want to go from here? Keep the discussion
>>> here in the mailing list, move it to the issue tracker, or somewhere else?
>>>
>> i'd like some more iteration on the basics, then perhaps a quick video
>> conference to solidify the thinking,
>> then set up a github project.
>>
>> -- Ronny
>>
>>
>>
>>>
>>> Cheers,
>>> Bruno.
>>>
>>>
>>> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <rpfannsc at redhat.com>
>>> wrote:
>>>
>>>> Problem: for the storage of helper objects that either tackle certain
>>>> global tracking details or that track information over the testprotocol
>>>> lifecycle of test items, we use monkeypatchs and generally just munge
>>>> around in either the pytest config object or item objects.
>>>>
>>>> I would like to propose a new API putting those details into
>>>> consideration.
>>>>
>>>>
>>>>
>>>>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
>>>> pytest session lifetime
>>>>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
>>>> run-test protocol cycle of item
>>>>
>>>> Each stash  would be a context manager and construction would get
>>>> access to both item and config.
>>>>
>>>> This would for example enable to express the junit xml logger object
>>>> and configuration as
>>>>
>>>> `config.get_stash(__name__, JunitXMlTracker)`
>>>>
>>>> Just as  it would allow other plugin to store node lifecycle related
>>>> details within the node using a well known mechanism
>>>>
>>>> Incidentally this would also be a good fit for the fixture system and
>>>> setup-state in general to store information.
>>>>
>>>> The basic assumption being that only the stashes of the items that are
>>>> currently active are valid, and other stashes are torn down,
>>>> then fixtures as well as the fixture request would nicely fit that
>>>> storage mechanism, and would also generalize across the node tree from
>>>> session down to individual items.
>>>>
>>>> (considering the layout, it might be sensible to even replace
>>>> config.get_stash with something
>>>> like session.get_stash)
>>>>
>>>> The idea is still rather fuzzy in my head and i would love to di either
>>>> text based brainstorming on it, or a actual video call.
>>>>
>>>> -- Ronny
>>>>
>>>> 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
>>>>
>>>
>>
>> --
>>
>> 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
>>
>>
>
> --
>
> 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/20191016/5c107ca7/attachment-0001.html>

From rpfannsc at redhat.com  Wed Oct 16 10:49:41 2019
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Wed, 16 Oct 2019 16:49:41 +0200
Subject: [pytest-dev] [proposal] global and per item data stashes
In-Reply-To: <CAN0FtzO1bBnyygqbQ7CXmTqWecywNUUvKq708yovPZLgezD2Tw@mail.gmail.com>
References: <CAA10jzPDuu2bZwKYzaOKJneu0TAV7YT=-0BO=X9mYz19HUR4OA@mail.gmail.com>
 <CA+RQFffEnt=XouphLMKq232oYOH4LZcdZkmw_vuHtaB4HWgYqw@mail.gmail.com>
 <CAA10jzO6_Ez9RqZGUFWBgHfUeG0Yz+zu5Ttd3ap-RQXNgQ8L6A@mail.gmail.com>
 <CAA10jzOff1UVNZMUhpKPzCK1kbZR+Yji_YsCs3HSk6-ecYzOVQ@mail.gmail.com>
 <CAN0FtzO1bBnyygqbQ7CXmTqWecywNUUvKq708yovPZLgezD2Tw@mail.gmail.com>
Message-ID: <CAA10jzNNDFc8kFoiQT-UbddKesD3hG9LgZsTWY4YAEd92w5HWw@mail.gmail.com>

Hi Victor,

i took a initial look and i believe the tooling can intersect

a "stash/storage" would be used for the live part,
and its tear-down could transfer the harvest details to a more
compact/permanent storage/location/bubble them up.

at work we are currently working on a service that stores/tracks test
results/logs/selenium screen-shots for test execution,
i marked it down as a research target for integration with pytest-harvest

- Ronny

On Wed, 16 Oct 2019 at 16:27, Victor Maryama <victor.maryama at gmail.com>
wrote:

> Hi guys! I am no expert, but maybe is this something that could replace or
> intersect with the functionality provided by
> https://smarie.github.io/python-pytest-harvest/ (fixture_store and
> results_bag fixtures)? And maybe the code that is saving fixture and test
> context information like in allure-pytest.
>
> Although probably it would require the stashes not to be torn down, in
> opposition to the original Ronny's idea.
>
> Le mer. 16 oct. 2019 ? 15:42, Ronny Pfannschmidt <rpfannsc at redhat.com> a
> ?crit :
>
>> a little side note as  i was  just having a little discussion about this
>> with a native speaker,
>> the word stash isn`t quite fitting the concept - the name scoped_storage
>> came to mind,
>> we might need to iterate on the concept name a bit to get to something
>> that makes deeper sense
>>
>> - Ronny
>>
>> On Wed, 16 Oct 2019 at 09:45, Ronny Pfannschmidt <rpfannsc at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <nicoddemus at gmail.com>
>>> wrote:
>>>
>>>> Hi Ronny,
>>>>
>>>> As you have shared this before in chat, at first glance it sounds like
>>>> a good idea!
>>>>
>>>> Some questions that we can probably elaborate on once we have something
>>>> more concrete to discuss:
>>>>
>>>> 1. You say "each stash  would be a context manager", but it is not
>>>> clear to me how this would work in practice, as most uses today that need
>>>> to decorate the object need to do it across multiple function calls (for
>>>> example, creating an object in `pytest_configure` and storing it in a
>>>> stash, only to retrieve the data later in another hook). Can you provide
>>>> examples to clarify this?
>>>>
>>> the value returned from get_stash would be the value the entering of the
>>> context manager yielded
>>> this also means that for a item or a class there may be multiple stashes
>>> over a test-run, as each stash would have been entered in a different
>>> lifecycles
>>>
>>>
>>>
>>>>
>>>> 2. If we are to use the "stash" for fixtures, we need  a way to specify
>>>> stashes whose other lifetimes than function and session, like class, module
>>>> and package. Any idea how this would look like?
>>>>
>>> those stashes would just be modelled on the belonging nodes, so fixtures
>>> for session, stashed on session, fixtures for class, stashed on class and
>>> so on
>>>
>>>
>>>
>>>>
>>>> Other than that, where do you want to go from here? Keep the discussion
>>>> here in the mailing list, move it to the issue tracker, or somewhere else?
>>>>
>>> i'd like some more iteration on the basics, then perhaps a quick video
>>> conference to solidify the thinking,
>>> then set up a github project.
>>>
>>> -- Ronny
>>>
>>>
>>>
>>>>
>>>> Cheers,
>>>> Bruno.
>>>>
>>>>
>>>> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <
>>>> rpfannsc at redhat.com> wrote:
>>>>
>>>>> Problem: for the storage of helper objects that either tackle certain
>>>>> global tracking details or that track information over the testprotocol
>>>>> lifecycle of test items, we use monkeypatchs and generally just munge
>>>>> around in either the pytest config object or item objects.
>>>>>
>>>>> I would like to propose a new API putting those details into
>>>>> consideration.
>>>>>
>>>>>
>>>>>
>>>>>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
>>>>> pytest session lifetime
>>>>>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
>>>>> run-test protocol cycle of item
>>>>>
>>>>> Each stash  would be a context manager and construction would get
>>>>> access to both item and config.
>>>>>
>>>>> This would for example enable to express the junit xml logger object
>>>>> and configuration as
>>>>>
>>>>> `config.get_stash(__name__, JunitXMlTracker)`
>>>>>
>>>>> Just as  it would allow other plugin to store node lifecycle related
>>>>> details within the node using a well known mechanism
>>>>>
>>>>> Incidentally this would also be a good fit for the fixture system and
>>>>> setup-state in general to store information.
>>>>>
>>>>> The basic assumption being that only the stashes of the items that are
>>>>> currently active are valid, and other stashes are torn down,
>>>>> then fixtures as well as the fixture request would nicely fit that
>>>>> storage mechanism, and would also generalize across the node tree from
>>>>> session down to individual items.
>>>>>
>>>>> (considering the layout, it might be sensible to even replace
>>>>> config.get_stash with something
>>>>> like session.get_stash)
>>>>>
>>>>> The idea is still rather fuzzy in my head and i would love to di
>>>>> either text based brainstorming on it, or a actual video call.
>>>>>
>>>>> -- Ronny
>>>>>
>>>>> 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
>>>>>
>>>>
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>
>> --
>>
>> 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
>>
> _______________________________________________
> 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/20191016/e5e760fd/attachment.html>

From nicoddemus at gmail.com  Thu Oct 24 08:45:48 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 24 Oct 2019 09:45:48 -0300
Subject: [pytest-dev] Future of pytest-xdist/execnet?
Message-ID: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>

Hi everyone,

For some time now execnet has been in maintenance only mode, and even so
very few people are willing to maintain it; lately just myself and I?m not
a good choice given that I don?t know the codebase at all, plus I have tons
on my plate already. This poses a problem because often we have bug reports
or feature requests in pytest-xdist which would require fixing or improving
execnet, and are currently left without solution.

Ronny and I have on occasion discussed the possibility of changing execnet?s
backend , with the current contenders being multiprocessing for local
distribution and mitogen for remote distribution.

I would like to write down some thoughts and gather opinions from the
mailing list members.
multiprocessing

Aside from not needing to maintain execnet anymore, being able to use
multiprocessing would bring several benefits:

   -

   pytest -s would work just fine, because multiprocessing does not use
   stdout/stderr for communication. This is a often requested feature but
   which we can?t (with current expertise) implement on execnet.
   -

   It would automatically support anything that can be picked to be
   transmitted across the wire. Currently execnet does not support custom user
   types and some builtins (frozen sets for example).

Without execnet we would lose the ability of running the tests in different
interpreter versions, but I believe this has been supplanted by tox in the
ecosystem.
mitogen

Using mitogen for remote execution would provide automatic bootstrap of the
Python environment, which is not currently supported by xdist?s ssh remote
execution, greatly limiting its usefulness in real-time scenarios.

This is Ronny?s idea and he can add more here if wanted.
pytest-xdist2?

All the changes mentioned above would break backward compatibility *hard*,
because details of the execnet implementation are currently exposed to
users in the command-line:

pytest -d --tx popen//python

And in several hooks:

def pytest_xdist_newgateway(gateway):
    """ called on new raw gateway creation. """

(gateway is an execnet object)

To incorporate the new backends, we would need to severely break both
command-line and existing hooks. Given the level of breakage this could
cause, just bumping the major version in this case doesn?t seem enough, it
would be a disservice to users given that probably nobody pins pytest-xdist
to <=2, and it would break the world with hard to understand error messages
once a first major release was released.

Because of this, we have been discussing creating a new package,
pytest-xdist2 (other suggestions are welcome), without any backward
compatibility guarantees with pytest-xdist.

pytest-xdist2 would, at first, only support local test distribution using
multiprocessing (-n flag), no new hooks, and no remote execution. I?ve made
a proof of concept here:

https://github.com/pytest-dev/pytest-xdist/pull/479

So it definitely seems possible. One immediate benefit is that the proof of
concept above supports pytest -s already, and can transfer anything that?s
pickled over the wire.

So I would like to know what people think of the above ideas, if they are
good/bad, and/or suggest alternatives that we are not seeing right now.

Ronny, please feel free to add to this email and correct anything I got
wrong.

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

From freddyrietdijk at fridh.nl  Thu Oct 24 09:22:32 2019
From: freddyrietdijk at fridh.nl (Freddy Rietdijk)
Date: Thu, 24 Oct 2019 15:22:32 +0200
Subject: [pytest-dev] Future of pytest-xdist/execnet?
In-Reply-To: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
References: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
Message-ID: <CAOQtOH2UmVAvGh0bW+ATtpWYFJ0v8=gZj8yF1eeYmXoEkjcPKA@mail.gmail.com>

Hi,

I think having a simple `pytest-multiprocessing` or `pytest-concurrent`
would be extremely useful and cover a lot of people's use cases and would
strongly recommend to have that as a separate plugin from something bigger
that does feature hooks and/or remote execution.. It seems though as such a
package already exists, https://github.com/reverbc/pytest-concurrent, which
offers --concmode and --concworkers instead.

Frederik

On Thu, Oct 24, 2019 at 2:46 PM Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi everyone,
>
> For some time now execnet has been in maintenance only mode, and even so
> very few people are willing to maintain it; lately just myself and I?m not
> a good choice given that I don?t know the codebase at all, plus I have tons
> on my plate already. This poses a problem because often we have bug reports
> or feature requests in pytest-xdist which would require fixing or
> improving execnet, and are currently left without solution.
>
> Ronny and I have on occasion discussed the possibility of changing execnet?s
> backend , with the current contenders being multiprocessing for local
> distribution and mitogen for remote distribution.
>
> I would like to write down some thoughts and gather opinions from the
> mailing list members.
> multiprocessing
>
> Aside from not needing to maintain execnet anymore, being able to use
> multiprocessing would bring several benefits:
>
>    -
>
>    pytest -s would work just fine, because multiprocessing does not use
>    stdout/stderr for communication. This is a often requested feature but
>    which we can?t (with current expertise) implement on execnet.
>    -
>
>    It would automatically support anything that can be picked to be
>    transmitted across the wire. Currently execnet does not support custom user
>    types and some builtins (frozen sets for example).
>
> Without execnet we would lose the ability of running the tests in
> different interpreter versions, but I believe this has been supplanted by
> tox in the ecosystem.
> mitogen
>
> Using mitogen for remote execution would provide automatic bootstrap of
> the Python environment, which is not currently supported by xdist?s ssh
> remote execution, greatly limiting its usefulness in real-time scenarios.
>
> This is Ronny?s idea and he can add more here if wanted.
> pytest-xdist2?
>
> All the changes mentioned above would break backward compatibility *hard*,
> because details of the execnet implementation are currently exposed to
> users in the command-line:
>
> pytest -d --tx popen//python
>
> And in several hooks:
>
> def pytest_xdist_newgateway(gateway):
>     """ called on new raw gateway creation. """
>
> (gateway is an execnet object)
>
> To incorporate the new backends, we would need to severely break both
> command-line and existing hooks. Given the level of breakage this could
> cause, just bumping the major version in this case doesn?t seem enough, it
> would be a disservice to users given that probably nobody pins pytest-xdist
> to <=2, and it would break the world with hard to understand error
> messages once a first major release was released.
>
> Because of this, we have been discussing creating a new package,
> pytest-xdist2 (other suggestions are welcome), without any backward
> compatibility guarantees with pytest-xdist.
>
> pytest-xdist2 would, at first, only support local test distribution using
> multiprocessing (-n flag), no new hooks, and no remote execution. I?ve
> made a proof of concept here:
>
> https://github.com/pytest-dev/pytest-xdist/pull/479
>
> So it definitely seems possible. One immediate benefit is that the proof
> of concept above supports pytest -s already, and can transfer anything
> that?s pickled over the wire.
>
> So I would like to know what people think of the above ideas, if they are
> good/bad, and/or suggest alternatives that we are not seeing right now.
>
> Ronny, please feel free to add to this email and correct anything I got
> wrong.
>
> 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/20191024/60237afc/attachment-0001.html>

From me at the-compiler.org  Thu Oct 24 09:22:49 2019
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 24 Oct 2019 15:22:49 +0200
Subject: [pytest-dev] Future of pytest-xdist/execnet?
In-Reply-To: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
References: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
Message-ID: <20191024132249.pqxtqzp45fj3nnnx@hooch.localdomain>

Hey,

On Thu, Oct 24, 2019 at 09:45:48AM -0300, Bruno Oliveira wrote:
> Because of this, we have been discussing creating a new package,
> pytest-xdist2 (other suggestions are welcome), without any backward
> compatibility guarantees with pytest-xdist.

pytest-[yz]dist? ;)

> pytest-xdist2 would, at first, only support local test distribution using
> multiprocessing (-n flag), no new hooks, and no remote execution.

Personally I've only used pytest-xdist for that (local multiprocessing), and I
bet there are other people for whom the same applies. If you add remote test
distribution to the mix, you'd win even more users over.

I guess the question is how many pytest-xdist users are left at that point, who
need the hooks and other advanced features. I'm guessing not that many, but I
could be wrong.

GitHub says that pytest-xdist is used by 4.7k repos.

Searching for "def pytest_xdist" on GitHub shows about 300 results:
https://github.com/search?p=1&q=%22def+pytest_xdist%22&type=Code

If you scroll through them, you'll see that almost all of them are because
people committed their virtualenvs, so it's from the xdist package itself.

I found something like 20 projects which actually use an xdist hook, some of
them pytest plugins (pytest_mozlog, pytest-sugar).

I'm guessing there will be more than 20 projects/people happy about the
problems such a rewrite would solve.

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/20191024/a6cb9e0b/attachment.sig>

From opensource at ronnypfannschmidt.de  Thu Oct 24 16:15:25 2019
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Thu, 24 Oct 2019 22:15:25 +0200
Subject: [pytest-dev] Future of pytest-xdist/execnet?
In-Reply-To: <CAOQtOH2UmVAvGh0bW+ATtpWYFJ0v8=gZj8yF1eeYmXoEkjcPKA@mail.gmail.com>
References: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
 <CAOQtOH2UmVAvGh0bW+ATtpWYFJ0v8=gZj8yF1eeYmXoEkjcPKA@mail.gmail.com>
Message-ID: <650cb216-27b1-9921-2a92-598fe209c31c@ronnypfannschmidt.de>

Hi Freddy,


unfortunately pytest-concurrent is fundamentally broken for managing 
fixtures and other details,
as things are my suggestion is to avoid it.


-- Ronny

Am 24.10.19 um 15:22 schrieb Rietdijk:
> Hi,
>
> I think having a simple `pytest-multiprocessing` or 
> `pytest-concurrent` would be extremely useful and cover a lot of 
> people's use cases and would strongly recommend to have that as a 
> separate plugin from something bigger that does feature hooks and/or 
> remote execution.. It seems though as such a package already exists, 
> https://github.com/reverbc/pytest-concurrent, which offers --concmode 
> and --concworkers instead.
>
> Frederik
>
> On Thu, Oct 24, 2019 at 2:46 PM Bruno Oliveira <nicoddemus at gmail.com 
> <mailto:nicoddemus at gmail.com>> wrote:
>
>     Hi everyone,
>
>     For some time now |execnet| has been in maintenance only mode, and
>     even so very few people are willing to maintain it; lately just
>     myself and I?m not a good choice given that I don?t know the
>     codebase at all, plus I have tons on my plate already. This poses
>     a problem because often we have bug reports or feature requests in
>     |pytest-xdist| which would require fixing or improving |execnet|,
>     and are currently left without solution.
>
>     Ronny and I have on occasion discussed the possibility of changing
>     |execnet|?s backend , with the current contenders being
>     |multiprocessing| for local distribution and |mitogen| for remote
>     distribution.
>
>     I would like to write down some thoughts and gather opinions from
>     the mailing list members.
>
>
>         multiprocessing
>
>     Aside from not needing to maintain |execnet| anymore, being able
>     to use |multiprocessing| would bring several benefits:
>
>      *
>
>         |pytest -s| would work just fine, because |multiprocessing|
>         does not use |stdout/stderr| for communication. This is a
>         often requested feature but which we can?t (with current
>         expertise) implement on |execnet|.
>
>      *
>
>         It would automatically support anything that can be picked to
>         be transmitted across the wire. Currently execnet does not
>         support custom user types and some builtins (frozen sets for
>         example).
>
>     Without |execnet| we would lose the ability of running the tests
>     in different interpreter versions, but I believe this has been
>     supplanted by |tox| in the ecosystem.
>
>
>         mitogen
>
>     Using |mitogen| for remote execution would provide automatic
>     bootstrap of the Python environment, which is not currently
>     supported by |xdist|?s ssh remote execution, greatly limiting its
>     usefulness in real-time scenarios.
>
>     This is Ronny?s idea and he can add more here if wanted.
>
>
>         pytest-xdist2?
>
>     All the changes mentioned above would break backward compatibility
>     *hard*, because details of the |execnet| implementation are
>     currently exposed to users in the command-line:
>
>     |pytest -d --tx popen//python |
>
>     And in several hooks:
>
>     |def pytest_xdist_newgateway(gateway): """ called on new raw
>     gateway creation. """ |
>
>     (|gateway| is an |execnet| object)
>
>     To incorporate the new backends, we would need to severely break
>     both command-line and existing hooks. Given the level of breakage
>     this could cause, just bumping the major version in this case
>     doesn?t seem enough, it would be a disservice to users given that
>     probably nobody pins pytest-xdist to |<=2|, and it would break the
>     world with hard to understand error messages once a first major
>     release was released.
>
>     Because of this, we have been discussing creating a new package,
>     |pytest-xdist2| (other suggestions are welcome), without any
>     backward compatibility guarantees with |pytest-xdist|.
>
>     |pytest-xdist2| would, at first, only support local test
>     distribution using |multiprocessing| (|-n| flag), no new hooks,
>     and no remote execution. I?ve made a proof of concept here:
>
>     https://github.com/pytest-dev/pytest-xdist/pull/479
>
>     So it definitely seems possible. One immediate benefit is that the
>     proof of concept above supports |pytest -s| already, and can
>     transfer anything that?s pickled over the wire.
>
>     So I would like to know what people think of the above ideas, if
>     they are good/bad, and/or suggest alternatives that we are not
>     seeing right now.
>
>     Ronny, please feel free to add to this email and correct anything
>     I got wrong.
>
>     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
>
>
> _______________________________________________
> 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/20191024/0dc14137/attachment.html>

From opensource at ronnypfannschmidt.de  Thu Oct 24 16:26:45 2019
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Thu, 24 Oct 2019 22:26:45 +0200
Subject: [pytest-dev] Fwd: Re:  Future of pytest-xdist/execnet?
In-Reply-To: <mailman.2075.1571948743.32316.pytest-dev@python.org>
References: <mailman.2075.1571948743.32316.pytest-dev@python.org>
Message-ID: <555cc9bc-19a5-11c5-362c-40f99429ebd0@ronnypfannschmidt.de>




-------- Weitergeleitete Nachricht --------
Betreff: 	Re: [pytest-dev] Future of pytest-xdist/execnet?
Datum: 	Thu, 24 Oct 2019 16:25:43 -0400
Von: 	pytest-dev-owner at python.org
An: 	ich at ronnypfannschmidt.de



Your message has been rejected, probably because you are not
subscribed to the mailing list and the list's policy is to prohibit
non-members from posting to it. If you think that your messages are
being rejected in error, contact the mailing list owner at
pytest-dev-owner at python.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20191024/435bdd39/attachment-0001.html>
-------------- next part --------------
An embedded message was scrubbed...
From: Ronny Pfannschmidt <ich at ronnypfannschmidt.de>
Subject: Re: [pytest-dev] Future of pytest-xdist/execnet?
Date: Thu, 24 Oct 2019 22:25:40 +0200
Size: 27869
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20191024/435bdd39/attachment-0001.eml>

From tgoodlet at gmail.com  Thu Oct 24 16:34:51 2019
From: tgoodlet at gmail.com (Tyler Goodlet)
Date: Thu, 24 Oct 2019 16:34:51 -0400
Subject: [pytest-dev] Future of pytest-xdist/execnet?
In-Reply-To: <650cb216-27b1-9921-2a92-598fe209c31c@ronnypfannschmidt.de>
References: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
 <CAOQtOH2UmVAvGh0bW+ATtpWYFJ0v8=gZj8yF1eeYmXoEkjcPKA@mail.gmail.com>
 <650cb216-27b1-9921-2a92-598fe209c31c@ronnypfannschmidt.de>
Message-ID: <CAOfDtvrHvUD5QBV==F9gfbuBgxvGhVtyKvRmzyn1TVZLO2Ng7w@mail.gmail.com>

Another one that might be worth taking a peek at is:
https://github.com/ansible/pytest-mp

I've never dug in personally but it always looked promising.

On Thu, Oct 24, 2019 at 4:22 PM RonnyPfannschmidt
<opensource at ronnypfannschmidt.de> wrote:
>
> Hi Freddy,
>
>
> unfortunately pytest-concurrent is fundamentally broken for managing fixtures and other details,
> as things are my suggestion is to avoid it.
>
>
> -- Ronny
>
> Am 24.10.19 um 15:22 schrieb   Rietdijk:
>
> Hi,
>
> I think having a simple `pytest-multiprocessing` or `pytest-concurrent` would be extremely useful and cover a lot of people's use cases and would strongly recommend to have that as a separate plugin from something bigger that does feature hooks and/or remote execution.. It seems though as such a package already exists, https://github.com/reverbc/pytest-concurrent, which offers --concmode and --concworkers instead.
>
> Frederik
>
> On Thu, Oct 24, 2019 at 2:46 PM Bruno Oliveira <nicoddemus at gmail.com> wrote:
>>
>> Hi everyone,
>>
>> For some time now execnet has been in maintenance only mode, and even so very few people are willing to maintain it; lately just myself and I?m not a good choice given that I don?t know the codebase at all, plus I have tons on my plate already. This poses a problem because often we have bug reports or feature requests in pytest-xdist which would require fixing or improving execnet, and are currently left without solution.
>>
>> Ronny and I have on occasion discussed the possibility of changing execnet?s backend , with the current contenders being multiprocessing for local distribution and mitogen for remote distribution.
>>
>> I would like to write down some thoughts and gather opinions from the mailing list members.
>>
>> multiprocessing
>>
>> Aside from not needing to maintain execnet anymore, being able to use multiprocessing would bring several benefits:
>>
>> pytest -s would work just fine, because multiprocessing does not use stdout/stderr for communication. This is a often requested feature but which we can?t (with current expertise) implement on execnet.
>>
>> It would automatically support anything that can be picked to be transmitted across the wire. Currently execnet does not support custom user types and some builtins (frozen sets for example).
>>
>> Without execnet we would lose the ability of running the tests in different interpreter versions, but I believe this has been supplanted by tox in the ecosystem.
>>
>> mitogen
>>
>> Using mitogen for remote execution would provide automatic bootstrap of the Python environment, which is not currently supported by xdist?s ssh remote execution, greatly limiting its usefulness in real-time scenarios.
>>
>> This is Ronny?s idea and he can add more here if wanted.
>>
>> pytest-xdist2?
>>
>> All the changes mentioned above would break backward compatibility hard, because details of the execnet implementation are currently exposed to users in the command-line:
>>
>> pytest -d --tx popen//python
>>
>> And in several hooks:
>>
>> def pytest_xdist_newgateway(gateway):
>>     """ called on new raw gateway creation. """
>>
>> (gateway is an execnet object)
>>
>> To incorporate the new backends, we would need to severely break both command-line and existing hooks. Given the level of breakage this could cause, just bumping the major version in this case doesn?t seem enough, it would be a disservice to users given that probably nobody pins pytest-xdist to <=2, and it would break the world with hard to understand error messages once a first major release was released.
>>
>> Because of this, we have been discussing creating a new package, pytest-xdist2 (other suggestions are welcome), without any backward compatibility guarantees with pytest-xdist.
>>
>> pytest-xdist2 would, at first, only support local test distribution using multiprocessing (-n flag), no new hooks, and no remote execution. I?ve made a proof of concept here:
>>
>> https://github.com/pytest-dev/pytest-xdist/pull/479
>>
>> So it definitely seems possible. One immediate benefit is that the proof of concept above supports pytest -s already, and can transfer anything that?s pickled over the wire.
>>
>> So I would like to know what people think of the above ideas, if they are good/bad, and/or suggest alternatives that we are not seeing right now.
>>
>> Ronny, please feel free to add to this email and correct anything I got wrong.
>>
>> Cheers,
>> Bruno
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From asottile+pytest at umich.edu  Thu Oct 24 16:49:56 2019
From: asottile+pytest at umich.edu (Anthony Sottile)
Date: Thu, 24 Oct 2019 13:49:56 -0700
Subject: [pytest-dev] Future of pytest-xdist/execnet?
In-Reply-To: <mailman.2077.1571948808.32316.pytest-dev@python.org>
References: <mailman.2077.1571948808.32316.pytest-dev@python.org>
Message-ID: <CA+dzEB=jJit5r3fw-L2nvUyPHCb7vcugyA+R+C7R_4vvG15jKA@mail.gmail.com>

Just my 2c, I think I might would be valuable to create two new plugins:
- one which handles local concurrency via multiprocessing (pipes, shmem,
etc.)
- one which handles remote concurrency (sockets, client/server, etc.)

from a usage standpoint I expect the 99% to be the former suggested plug-in
(for current usage of xdist).  At least for me all of my (admittedly
little) usage is of vanilla xdist on the local machine. I also think by
separating concerns the two plugins could focus more on implementing their
core functionality (and therefore do a better job of it).

only if there's very clear identical behavior should we consider making a
shared library or including in core.

I definitely think there's a lot of opportunities here to improve on the
status quo (and provide some significant value for those currently using
xdist). I've collected a few (I don't want to call them complaints) words
from a few heavy users (pip, cryptography to name a few) where I think a
new approach could provide significant improvements

while they're both essentially distributed systems problems, I think the
local vs. remote plugins can probably take slightly different
approaches/trade-offs on reliability (especially with local multiprocessing
likely being much more reliable)

I'd be happy to help work/help on this, though I probably don't have the
cycles to properly "own" such an effort

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

From opensource at ronnypfannschmidt.de  Thu Oct 24 17:19:54 2019
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Thu, 24 Oct 2019 23:19:54 +0200
Subject: [pytest-dev] Building the Rationale for upcoming changes in the
 node construction apis
Message-ID: <8921b64a-8fba-d7e9-b35c-f3e6104fc896@ronnypfannschmidt.de>

Hi everyone,

in https://github.com/pytest-dev/pytest/pull/5975 i have startet to 
prepare a POC with a ambitious goal,
i want to remove much of the mind boggling smartness from the constructors
and i want to streamline note constructors in order to reduce the 
coupling in the different types of nodes.

The tight coupling and tricky construction of nodes has repeatedly 
foiled my attempts to refactor both fixtures/fixture caching and 
setupstate as well as
actually introducing FunctionDefinition in the public api (and shifting 
generate_tests to it) and retiring Instance.

So from my pov its? not sustainable to leave them be, as they prevent 
other required improvements.
However as far as i can tell its next to impossible without breaking things.

The Rough idea i have for iteratively solving it is to

a) introduce Node.from_parent as the convention for node construction
b) deprecate Node.__init__ being invoked outside of such a function
c) destroy all the things and have a cupcake

Whats needed in addition is a slightly? more eloquent version of the 
description for the? documentation.

-- Ronny


From nicoddemus at gmail.com  Thu Oct 24 17:23:22 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 24 Oct 2019 18:23:22 -0300
Subject: [pytest-dev] Building the Rationale for upcoming changes in the
 node construction apis
In-Reply-To: <8921b64a-8fba-d7e9-b35c-f3e6104fc896@ronnypfannschmidt.de>
References: <8921b64a-8fba-d7e9-b35c-f3e6104fc896@ronnypfannschmidt.de>
Message-ID: <CA+RQFfd_dBdN6Me085RBVk5k-6_-JNGey477=6=wgUf0td2dog@mail.gmail.com>

Hi Ronny,

Thanks for all the hard work on this, I'm sure the final result will be as
good/valuable as all the internal mark refactoring.

Cheers,
Bruno

On Thu, Oct 24, 2019 at 6:20 PM RonnyPfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi everyone,
>
> in https://github.com/pytest-dev/pytest/pull/5975 i have startet to
> prepare a POC with a ambitious goal,
> i want to remove much of the mind boggling smartness from the constructors
> and i want to streamline note constructors in order to reduce the
> coupling in the different types of nodes.
>
> The tight coupling and tricky construction of nodes has repeatedly
> foiled my attempts to refactor both fixtures/fixture caching and
> setupstate as well as
> actually introducing FunctionDefinition in the public api (and shifting
> generate_tests to it) and retiring Instance.
>
> So from my pov its  not sustainable to leave them be, as they prevent
> other required improvements.
> However as far as i can tell its next to impossible without breaking
> things.
>
> The Rough idea i have for iteratively solving it is to
>
> a) introduce Node.from_parent as the convention for node construction
> b) deprecate Node.__init__ being invoked outside of such a function
> c) destroy all the things and have a cupcake
>
> Whats needed in addition is a slightly  more eloquent version of the
> description for the  documentation.
>
> -- Ronny
>
> _______________________________________________
> 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/20191024/6f3ee87f/attachment-0001.html>

From nicoddemus at gmail.com  Thu Oct 24 20:11:49 2019
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 24 Oct 2019 21:11:49 -0300
Subject: [pytest-dev] pytest 5.2.2
Message-ID: <CA+RQFffEt1h3iraoBEcc7gpHGbHwJT9GamtQA2t3HFeBfWUudA@mail.gmail.com>

pytest 5.2.2 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:

* Albert Tugushev
* Andrzej Klajnert
* Anthony Sottile
* Bruno Oliveira
* Daniel Hahler
* Florian Bruhin
* Nattaphoom Chaipreecha
* Oliver Bestwalter
* Philipp Loose
* Ran Benita
* Victor Maryama
* Yoav Caspi


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

From isaulv at gmail.com  Fri Oct 25 09:50:28 2019
From: isaulv at gmail.com (Isaul Vargas)
Date: Fri, 25 Oct 2019 09:50:28 -0400
Subject: [pytest-dev] Fwd:  Future of pytest-xdist/execnet?
In-Reply-To: <CAFB36JEu5Q+p--iaRsdcc6TO+bhQAcYkLoJBwWVdVaV4ci=_oA@mail.gmail.com>
References: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
 <CAFB36JEu5Q+p--iaRsdcc6TO+bhQAcYkLoJBwWVdVaV4ci=_oA@mail.gmail.com>
Message-ID: <CAFB36JGn29t_oZrUry8eAkd=xEi3ZFHohK5g_suNwQ4AczqAsw@mail.gmail.com>

This looks promising on the surface. I think we should outline what a new
concurrent test runner should look like.
These are things in my wish list:
* Tests are ran as a queue for each process. Currently x-dist batches the
tests to N workers, and maybe grabs a test or two in that batch. But if any
test takes a lot longer than expected, that batch is held up.
* The ability to pin tests to a worker. Maybe you have a class of tests
that need a single shared resource that would be difficult to pickle, so
using a marker allows you to do this. There should be markers to allow
grouping of tests to a single worker. Probably at the class and module
level.
* Add tooling to make it easy for fixtures to share data among processes.
Maybe a fixture runs a long process to generate data, but the data is
easily pickleable. There should be way to have a fixture initialize once,
and share the result with other processes.
* Allow some form of locking for function scope fixtures so that they can
block when running concurrently. This could be useful for things that are
complicated to share, but you want only one process to run at at time
during setup or teardown.


I'll be happy to test this new project and provide feedback. I am really
excited that is happening.

On Thu, Oct 24, 2019 at 8:46 AM Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi everyone,
>
> For some time now execnet has been in maintenance only mode, and even so
> very few people are willing to maintain it; lately just myself and I?m not
> a good choice given that I don?t know the codebase at all, plus I have tons
> on my plate already. This poses a problem because often we have bug reports
> or feature requests in pytest-xdist which would require fixing or
> improving execnet, and are currently left without solution.
>
> Ronny and I have on occasion discussed the possibility of changing execnet?s
> backend , with the current contenders being multiprocessing for local
> distribution and mitogen for remote distribution.
>
> I would like to write down some thoughts and gather opinions from the
> mailing list members.
> multiprocessing
>
> Aside from not needing to maintain execnet anymore, being able to use
> multiprocessing would bring several benefits:
>
>    -
>
>    pytest -s would work just fine, because multiprocessing does not use
>    stdout/stderr for communication. This is a often requested feature but
>    which we can?t (with current expertise) implement on execnet.
>    -
>
>    It would automatically support anything that can be picked to be
>    transmitted across the wire. Currently execnet does not support custom user
>    types and some builtins (frozen sets for example).
>
> Without execnet we would lose the ability of running the tests in
> different interpreter versions, but I believe this has been supplanted by
> tox in the ecosystem.
> mitogen
>
> Using mitogen for remote execution would provide automatic bootstrap of
> the Python environment, which is not currently supported by xdist?s ssh
> remote execution, greatly limiting its usefulness in real-time scenarios.
>
> This is Ronny?s idea and he can add more here if wanted.
> pytest-xdist2?
>
> All the changes mentioned above would break backward compatibility *hard*,
> because details of the execnet implementation are currently exposed to
> users in the command-line:
>
> pytest -d --tx popen//python
>
> And in several hooks:
>
> def pytest_xdist_newgateway(gateway):
>     """ called on new raw gateway creation. """
>
> (gateway is an execnet object)
>
> To incorporate the new backends, we would need to severely break both
> command-line and existing hooks. Given the level of breakage this could
> cause, just bumping the major version in this case doesn?t seem enough, it
> would be a disservice to users given that probably nobody pins pytest-xdist
> to <=2, and it would break the world with hard to understand error
> messages once a first major release was released.
>
> Because of this, we have been discussing creating a new package,
> pytest-xdist2 (other suggestions are welcome), without any backward
> compatibility guarantees with pytest-xdist.
>
> pytest-xdist2 would, at first, only support local test distribution using
> multiprocessing (-n flag), no new hooks, and no remote execution. I?ve
> made a proof of concept here:
>
> https://github.com/pytest-dev/pytest-xdist/pull/479
>
> So it definitely seems possible. One immediate benefit is that the proof
> of concept above supports pytest -s already, and can transfer anything
> that?s pickled over the wire.
>
> So I would like to know what people think of the above ideas, if they are
> good/bad, and/or suggest alternatives that we are not seeing right now.
>
> Ronny, please feel free to add to this email and correct anything I got
> wrong.
>
> 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/20191025/b35d6f59/attachment-0001.html>

From opensource at ronnypfannschmidt.de  Fri Oct 25 15:45:31 2019
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Fri, 25 Oct 2019 21:45:31 +0200
Subject: [pytest-dev] Fwd: Future of pytest-xdist/execnet?
In-Reply-To: <CAFB36JGn29t_oZrUry8eAkd=xEi3ZFHohK5g_suNwQ4AczqAsw@mail.gmail.com>
References: <CA+RQFfcHa7BeW5CaFHSs_eqMYJrNpqDQSwiTxVQnOaa0nrQ24A@mail.gmail.com>
 <CAFB36JEu5Q+p--iaRsdcc6TO+bhQAcYkLoJBwWVdVaV4ci=_oA@mail.gmail.com>
 <CAFB36JGn29t_oZrUry8eAkd=xEi3ZFHohK5g_suNwQ4AczqAsw@mail.gmail.com>
Message-ID: <a37d1df3-2c98-96a8-1eb4-e9daeacf5c2f@ronnypfannschmidt.de>

Hi Isaul

Am 25.10.19 um 15:50 schrieb Isaul Vargas:
> This looks promising on the surface. I think we should?outline what a 
> new concurrent test runner should look?like.
> These are things in my wish list:
> * Tests are ran as a queue for each process. Currently x-dist batches 
> the tests to N workers, and maybe grabs a test or two in that batch. 
> But if any test takes a lot longer than expected, that batch is held up.
We intend to add richer sheduling patters (which in turn will need richr 
communication about collection (marks, fixtures, parameters)
> * The ability to pin tests to a worker. Maybe you have a class of 
> tests that need a single shared resource that would be difficult to 
> pickle, so using a marker allows you to do this. There should be 
> markers to allow grouping of tests to a single worker. Probably at the 
> class and module level.
dito
> * Add tooling to make it easy for fixtures to share data among 
> processes. Maybe a fixture runs a long process to generate data, but 
> the data is easily pickleable. There should be way to have a fixture 
> initialize once, and share the result with other processes.
we will introduce something to detail? shared resources, but we want 
make fixtures that are inter-process, its just not possible to get 
sensibly right
> * Allow some form of locking for function scope fixtures so that they 
> can block when running concurrently. This could be useful for things 
> that are complicated to share, but you want only one process to run at 
> at time during setup or teardown.

i believe a resource hand-off protocol can be integrated with scheduling,
this detail will need careful design work


-- Ronny


>
>
> I'll be happy to test this new project and provide feedback. I am 
> really excited that is happening.
>
> On Thu, Oct 24, 2019 at 8:46 AM Bruno Oliveira <nicoddemus at gmail.com 
> <mailto:nicoddemus at gmail.com>> wrote:
>
>     Hi everyone,
>
>     For some time now |execnet| has been in maintenance only mode, and
>     even so very few people are willing to maintain it; lately just
>     myself and I?m not a good choice given that I don?t know the
>     codebase at all, plus I have tons on my plate already. This poses
>     a problem because often we have bug reports or feature requests in
>     |pytest-xdist| which would require fixing or improving |execnet|,
>     and are currently left without solution.
>
>     Ronny and I have on occasion discussed the possibility of changing
>     |execnet|?s backend , with the current contenders being
>     |multiprocessing| for local distribution and |mitogen| for remote
>     distribution.
>
>     I would like to write down some thoughts and gather opinions from
>     the mailing list members.
>
>
>         multiprocessing
>
>     Aside from not needing to maintain |execnet| anymore, being able
>     to use |multiprocessing| would bring several benefits:
>
>      *
>
>         |pytest -s| would work just fine, because |multiprocessing|
>         does not use |stdout/stderr| for communication. This is a
>         often requested feature but which we can?t (with current
>         expertise) implement on |execnet|.
>
>      *
>
>         It would automatically support anything that can be picked to
>         be transmitted across the wire. Currently execnet does not
>         support custom user types and some builtins (frozen sets for
>         example).
>
>     Without |execnet| we would lose the ability of running the tests
>     in different interpreter versions, but I believe this has been
>     supplanted by |tox| in the ecosystem.
>
>
>         mitogen
>
>     Using |mitogen| for remote execution would provide automatic
>     bootstrap of the Python environment, which is not currently
>     supported by |xdist|?s ssh remote execution, greatly limiting its
>     usefulness in real-time scenarios.
>
>     This is Ronny?s idea and he can add more here if wanted.
>
>
>         pytest-xdist2?
>
>     All the changes mentioned above would break backward compatibility
>     *hard*, because details of the |execnet| implementation are
>     currently exposed to users in the command-line:
>
>     |pytest -d --tx popen//python |
>
>     And in several hooks:
>
>     |def pytest_xdist_newgateway(gateway): """ called on new raw
>     gateway creation. """ |
>
>     (|gateway| is an |execnet| object)
>
>     To incorporate the new backends, we would need to severely break
>     both command-line and existing hooks. Given the level of breakage
>     this could cause, just bumping the major version in this case
>     doesn?t seem enough, it would be a disservice to users given that
>     probably nobody pins pytest-xdist to |<=2|, and it would break the
>     world with hard to understand error messages once a first major
>     release was released.
>
>     Because of this, we have been discussing creating a new package,
>     |pytest-xdist2| (other suggestions are welcome), without any
>     backward compatibility guarantees with |pytest-xdist|.
>
>     |pytest-xdist2| would, at first, only support local test
>     distribution using |multiprocessing| (|-n| flag), no new hooks,
>     and no remote execution. I?ve made a proof of concept here:
>
>     https://github.com/pytest-dev/pytest-xdist/pull/479
>
>     So it definitely seems possible. One immediate benefit is that the
>     proof of concept above supports |pytest -s| already, and can
>     transfer anything that?s pickled over the wire.
>
>     So I would like to know what people think of the above ideas, if
>     they are good/bad, and/or suggest alternatives that we are not
>     seeing right now.
>
>     Ronny, please feel free to add to this email and correct anything
>     I got wrong.
>
>     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
>
>
> _______________________________________________
> 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/20191025/abdd3fa7/attachment-0001.html>