[bug#61527] [PATCH] Add edgelist graph backend

[Kyle Andrews]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Kyle,
>
> Thank you for your inputs on the topic. :-)
>
>
> On lun., 27 févr. 2023 at 23:48, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Is “CSV edge list” some sort of a standard format, or is it more of an
>> idea you came up with?
>
> In addition to Ludo’s suggestions below, and commenting your answer [1],
> instead of “edgelist” backend – which seems well documented by igraph so
> it could be confusing for igraph folk, if any :-) – instead of
> “edgelist” backend I would use “csv”.  WDYT?

I agree 'csv' would be less confusing since in reality there are two
(normalized) tables embedded in one in the output.

> Quoting [1] for context:
>
>> > Here, I would add the description of the data as header of the CSV-like
>> > file.  For instance, something:
>> >
>> > --8<---------------cut here---------------start------------->8---
>> > # type, name-or-edge1, item-or-edge2
>> > # package, name, item
>> > # depends, edge1, edge2
>> > --8<---------------cut here---------------end--------------->8---
>>
>> I toyed with calling columns 2 and 3 "parent/child", "source/sink",
>> "input/output", "origin/destination". The "input/output" option sounds
>> the best to me.
>
> This “input/output” does not sound to me.  I would keep something like:
>
> --8<---------------cut here---------------start------------->8---
> # type, name-or-from, vertex-or-to
> # package, name, vertex
> # depends, from, to
> --8<---------------cut here---------------end--------------->8---

I like the name "table" for the first column following my rationale
above. For the second and third columns my sense of style and experience
working with data in R, I tend to prefer shorter vaguer names which are
easier to type. I hope it should be clear from context what is a label
for a vertex and what is an id for vertex. It would make more sense to
me to explain the meaning of each column in a "data dictionary" included
in the documentation, rather than sacrifice interactive convenience.

> Thinking a bit about this format, I agree with you that this “format”
> covers various needs feeding Python, R, etc. graph libraries.  And it is
> easy to filter via plain pipe “| grep depends“ or else.

Exactly.

>
> 1: <878rgynpox.fsf@posteo.net">https://issues.guix.gnu.org/msgid/878rgynpox.fsf@posteo.net>
>
>
>> The patch LGTM but we’ll need a couple more things:
>>
>>   1. Maybe emitting extra metadata as Simon suggested.

Mostly done depending on whether you will be satisfied with my "data
dictionary" idea.

>>   2. Adding documentation under “Invoking guix graph”.  In particular,
>>      it’d be nice to have an example showing how to query the generated
>>      CSV with igraph.

I have not added an example yet but I did mention the backend in the
documentation with a short description.

>>   3. Ideally a full patch with commit log as generated with ‘git
>>      format-patch’.  :-)

>> Could you send an updated patch?

Sorry, I tried to send an updated patch without reading (2) closely
enough. So, it's missing the example. I also want to add the data
dictionary I mentioned above.

I used git send-email for this task.

--8<---------------cut here---------------start------------->8---
git send-email *.patch --to=guix-patches@gnu.org
--8<---------------cut here---------------end--------------->8---

Is that the preferred way to do it? I'm not quite sure how debbugs
associates the issue numbers.

>
> Let me know if you need help. :-)

Thanks, for the offer! I really appreciate your patience.

> Cheers,
> simon