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 <rpfan...@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@python.org > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
