unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Roel Janssen <roel@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 27907@debbugs.gnu.org
Subject: [bug#27907] [PATCH] graph: Provide access to the package record in the emit
Date: Fri, 25 Aug 2017 11:00:51 +0200	[thread overview]
Message-ID: <rbushggt41o.fsf@gnu.org> (raw)
In-Reply-To: <87inhchab4.fsf@gnu.org>


Ludovic Courtès writes:

> Hi!
>
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> I would like to expand the Cypher back-end and in the long run add a
>>> SPARQL graph back-end to GNU Guix.  For this, I will need to have access
>>> to the package records inside the emit-* functions.
>>>
>>> This patch makes this change by essentially changing the "label"
>>> parameter of the emit-* functions passed as "(node-label head)" into a
>>> "node" parameter, passed as "head".
>>>
>>> The rest of the patch adapts the current emit-* functions to this
>>> change.
>>>
>>> I tested the Graphviz, D3js, and Cypher back-ends, and all seem to work
>>> as before.
>>>
>>> Is it OK to apply this change?
>>
>> Sure, looks good to me!
>
> Actually no!  :-)
>
> The problem was that it broke all non-package-related “node types” (like
> “guix graph -t references”), and it had the problem that it ignores the
> ‘label’ procedure in <node-type>.  And “make check” failed.
>
> So I reverted it in 5e60bef9802e448924f889d34d95a249b008652c.  We need
> to rethink about it.
>
> Cheers,
> Ludo’.

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.

If this sounds like a good idea I'll write a new patch.  And while I'm
at it, what set of commands fully cover the graph code for all node
types?  Just all variants in 'guix graph --type=X'?

Thanks!

Kind regards,
Roel Janssen

  reply	other threads:[~2017-08-25  9:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-01 14:40 [bug#27907] [PATCH] graph: Provide access to the package record in the emit Roel Janssen
2017-08-01 19:25 ` Ludovic Courtès
2017-08-01 22:47   ` bug#27907: " Roel Janssen
2017-08-24 22:26   ` [bug#27907] " Ludovic Courtès
2017-08-25  9:00     ` Roel Janssen [this message]
2017-08-25 14:50       ` Ludovic Courtès
2017-08-25 16:19         ` Roel Janssen
2017-08-26  8:02           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rbushggt41o.fsf@gnu.org \
    --to=roel@gnu.org \
    --cc=27907@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).