Subject: [bug#27907] [PATCH] graph: Provide access to the package record in the emit

From: [email-masked] (Ludovic Courtès)
Date: Sat, 26 Aug 2017 10:02:53 +0200

Roel Janssen <[email-masked]> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <[email-masked]> skribis:
>>
>>> Oops!  I am sorry about this.  Would it not break if we include a check for whether
>>> the node type is a package or not.  Then, non-package node types are
>>> handled the “old way” and packages are handled the “new way”.
>>>
>>> I think we cannot have a generic way of exposing the specifics of a node
>>> type, so if we need to expose more information for the other node types,
>>> we have to add a type-specific implementation.
>>
>> Actually, we might need to discuss the specifics of why you wanted to do
>> it in the first place.  :-)
>>
>> It is to pass extra rendering info to the backends?  (It would be
>> helpful for instance to adjust the node color or size depending on
>> certain parameters such as its size or number of dependents.)
>
> Not necessarily rendering information, even though it could improve the
> displayment of packages like you say.  I'd like to export more
> information to a graph database, so that the packages can be searched,
> explored and linked to in a graph that also contains stuff like how
> programs were run and what files that run produced.
>
> So, this is essentially an interoperability thing for communicating with
> other systems.

So I think an option would be to pass an extra property alist to the
‘emit-node’ and ‘emit-edge’ procedures of the backend.  The node type
would produce that alist and it would be up to the backend to make sense
of it.  Something along these lines.  WDYT?

Ludo’.