<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">a little side note as i was just having a little discussion about this with a native speaker,</div><div class="gmail_default" style="font-family:monospace,monospace">the word stash isn`t quite fitting the concept - the name scoped_storage came to mind,</div><div class="gmail_default" style="font-family:monospace,monospace">we might need to iterate on the concept name a bit to get to something that makes deeper sense</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">- Ronny<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Oct 2019 at 09:45, Ronny Pfannschmidt <<a href="mailto:rpfannsc@redhat.com">rpfannsc@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira <<a href="mailto:nicoddemus@gmail.com" target="_blank">nicoddemus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Ronny,<div><br></div><div>As you have shared this before in chat, at first glance it sounds like a good idea!</div><div><br></div><div>Some questions that we can probably elaborate on once we have something more concrete to discuss:</div><div><br></div><div>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?</div></div></div></blockquote><div><div style="font-family:monospace,monospace" class="gmail_default">the value returned from get_stash would be the value the entering of the context manager yielded</div><div style="font-family:monospace,monospace" class="gmail_default">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 <br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>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?</div></div></div></blockquote><div><div style="font-family:monospace,monospace" class="gmail_default">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</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>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?</div></div></div></blockquote><div><div style="font-family:monospace,monospace" class="gmail_default">i'd like some more iteration on the basics, then perhaps a quick video conference to solidify the thinking,</div><div style="font-family:monospace,monospace" class="gmail_default">then set up a github project. </div></div><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">-- Ronny</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>Cheers,</div><div>Bruno.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <<a href="mailto:rpfannsc@redhat.com" target="_blank">rpfannsc@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>P<span class="gmail_default" style="font-family:monospace,monospace">roblem: 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.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">I would like to propose a new API putting those details into consideration.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"> config.get_stash(owner, type=pytest.NamespaceStash) # valid over the pytest session lifetime<br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"> item.get_stash(owner, type=pytest.NamespaceStash) # valid across the run-test protocol cycle of item<br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">Each stash would be a context manager and construction would get access to both item and config.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">This would for example enable to express the junit xml logger object and configuration as <br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">`config.get_stash(__name__, JunitXMlTracker)`<br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">Just as it would allow other plugin to store node lifecycle related details within the node using a well known mechanism<br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">Incidentally this would also be a good fit for the fixture system and</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">setup-state in general to store information.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">The basic assumption being that only the stashes of the items that are currently active are valid, and other stashes are torn down,</span></div><div><span class="gmail_default" style="font-family:monospace,monospace">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.</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">(considering the layout, it might be sensible to even replace config.get_stash with something <br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">like session.get_stash)</span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace">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.<br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"><br></span></div><div><span class="gmail_default" style="font-family:monospace,monospace"></span>-<span class="gmail_default" style="font-family:monospace,monospace"></span>- <span class="gmail_default" style="font-family:monospace,monospace">Ronny</span><br></div><div><div dir="ltr"><div dir="ltr"><pre cols="72">Red Hat GmbH, <a href="http://www.de.redhat.com/" target="_blank">http://www.de.redhat.com/</a>, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander</pre></div></div></div></div>
_______________________________________________<br>
pytest-dev mailing list<br>
<a href="mailto:pytest-dev@python.org" target="_blank">pytest-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/pytest-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/pytest-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><pre cols="72">Red Hat GmbH, <a href="http://www.de.redhat.com/" target="_blank">http://www.de.redhat.com/</a>, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander</pre></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><pre cols="72">Red Hat GmbH, <a href="http://www.de.redhat.com/" target="_blank">http://www.de.redhat.com/</a>, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander</pre></div></div>