[pytest-dev] [proposal] global and per item data stashes

[Ronny Pfannschmidt]

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>