Hi Kyle, Thank you for your inputs on the topic. :-) On lun., 27 févr. 2023 at 23:48, Ludovic Courtès 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? 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--- 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. 1: > The patch LGTM but we’ll need a couple more things: > > 1. Maybe emitting extra metadata as Simon suggested. > > 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. > > 3. Ideally a full patch with commit log as generated with ‘git > format-patch’. :-) > > Could you send an updated patch? Let me know if you need help. :-) Cheers, simon