[bitbake-devel] [PATCH 6/7] bitbake: event: adding events to allow bbclasses to push custom info

[Richard Purdie]

On Mon, 2013-09-16 at 14:56 +0100, Damian, Alexandru wrote:
> On Mon, Sep 16, 2013 at 2:46 PM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:

> Your explanation in the commit message isn't as detailed as it could
>         be.
>         
>         I'm guessing but I suspect the problem we have is that the
>         event cannot
>         be rebuilt on the other side of an XMLRPC connection without
>         having the
>         event class in a common namespace?
>         
>         This is therefore a hack to allow the event to exist in all
>         the client
>         side namespaces.
> 
> 
> [Alex] Yep, this is an ugly hack.

In future *please* put this kind of information into commit messages.
I'm having a lot of trouble with these patches as the commit messages
don't give me all the information I need to review them.


>  
>         
>         Ideally we should really have an API which allows the classes
>         themselves
>         to declare their event formats and not require adding to
>         event.py every
>         time a new piece of code/event is added.

> 
> [Alex] I would favor a single "GenericEvent" that will take a set of
> defined parameters,
> that would allow "subclassing" at runtime - sort of introspection if
> you will.
> 
> Something like this:
> 
> 
> class GenericInfo(Event):
> 
>     def __init__(self, type, data):
>         Event.__init__(self)
>         self._type = type
>         self._data = data
> 
> with a call like
> 
> 
> bb.event.fire(bb.event.GenericInfo("PackageInfo", pkginfolist),
> e.data)
> 
> 
> the UI handlers / anybody would subscribe to GenericInfo events, 
> and the processing code would look like:
> 
> 
> if isinstance(event, bb.event.GenericInfo):
>     if event._type == "PackageInfo":
>          savePackageInfo(event)
>     elif event._type == "PackageFileSizes":
>         ....
> 

Lets do it but can you:

a) Stop using the underscores please. I know some older events have them
but the data is not internal so lets not persist broken syntax going
forward.
b) Call this MetadataEvent and put in a header comment explaining what
it is and why/when you'd use it.
c) Convert the user of PackageInfo in OE-Core to use the new event if it
is available, falling back to PackageInfo.
d) Update hob to accept the new event

c/d can come later but I do want to see patches for them ultimately.
We'll remove PackageInfo in the 1.6 cycle.

Cheers,

Richard