>Can you provide a use case for this storage? Perhaps we can use existing cases and see how they would like with the new API. ^ I agree it'd be good to see a practical example. I'm guessing this is to address what the ``pytest_namespace`` stuff (at least in the `config.objects` case) used to fulfil?
I know that with a project I've been meaning to get back to (`pytestlab` or whatever it turns into) we wanted to solve this problem but for managing testing resources and environments (eg here: https://github.com/sangoma/pytestlab/blob/master/pytest_lab/map.py#L13). I know for the purpose of system testing other full services using pytest we wanted to have a data store that was network transparent as well to meet the needs of distributed test runs that require synchronization and other protocols between inter-test stages. Having a base system + API in pytest core would make building a solution to such problems that much easier. Anyway just thinking out loud. Tyler Goodlet On Fri, Oct 27, 2017 at 1:55 PM, Bruno Oliveira <nicodde...@gmail.com> wrote: > Hi Ronny, > > Can you provide a use case for this storage? Perhaps we can use existing > cases and see how they would like with the new API. > > For example, pytest-html currently attaches an "extra" dictionary to > items. How could pytest-html make use of the new API? > > Another example is the core junitxml plugin, which adds new items that > should go into the reporty by using a fixture. How it would look like to > customize the report using the new API? > > Cheers, > Bruno. > > On Fri, Oct 27, 2017 at 2:58 PM RonnyPfannschmidt < > opensou...@ronnypfannschmidt.de> wrote: > >> hi everyone >> >> since a while now i feel the lack of a place where i can store objects >> that belong to some pytest plugin but shouldn't be plugins themselves >> >> i came up with an idea for a basic api and would like to get feedback >> from it >> >> at the basic level there would be a `config.objects` or `item.objects` >> as "immutable" mapping with 4 extra methods to mutate, i#ll just show >> the proposed effects >> >> get_or_create(tp, *k, **kw): >> if tp not in self: >> self[tp] = tp(*k, **kw) >> return self[tp] >> create(self, tp, *k, **kw): >> if tp in self: >> raise KeyError(tp) >> self[tp] = tp(*k, **kw) >> return self.tp >> >> add(obj): >> tp = type(obj) >> if tp in self: >> raise KeyError(tp) >> self[tp] = obj >> >> remove(self, obj): >> del self[type(obj)] >> >> discard(self, obj): >> self.pop(type(obj), None) >> >> by adding such a storage it will be a lot more easy to just put things >> on items and reports >> >> >> -- Ronny >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
