[pytest-dev] proposal - type-keyed storage for extension objects/metadata in config/items

[Tyler Goodlet]

>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 <nicoddemus at 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 <
> opensource at 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 at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20171027/a239bbd4/attachment.html>