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 <rpfan...@redhat.com> wrote: > > > On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <nicodde...@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 <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 >>> >> > > -- > > 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@python.org https://mail.python.org/mailman/listinfo/pytest-dev
