[PATCH 0/1] guix: graph: Add 'plain' backend.

  • Done
  • quality assurance status badge
Details
4 participants
  • Ludovic Courtès
  • Mathieu Othacehe
  • Ricardo Wurmus
  • zimoun
Owner
unassigned
Submitted by
zimoun
Severity
normal
Z
Z
zimoun wrote on 17 Sep 2020 21:39
(address . guix-patches@gnu.org)(name . zimoun)(address . zimon.toutoune@gmail.com)
20200917193931.14699-1-zimon.toutoune@gmail.com
Dear,

I am always annoyed when I use "guix graph" because most of the time I run:

guix graph htop | grep label

or something along these lines. Instead, the patch avoids the grep part:

Toggle snippet (21 lines)
$ ./pre-inst-env guix graph -b plain htop
htop@3.0.2
autoconf@2.69
perl@5.30.2
m4@1.4.18
automake@1.16.2
autoconf-wrapper@2.69
guile@2.0.14
pkg-config@0.29.2
libffi@3.3
bash-minimal@5.0.16
libunistring@0.9.10
libltdl@2.4.6
libgc@8.0.4
gmp@6.2.0
bash@5.0.16
readline@8.0.4
ncurses@6.2


It is then easier to pipe with other Guix commands, for example:

Toggle snippet (17 lines)
$ guix build $(./pre-inst-env guix graph -b plain htop | grep bash)
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
0.9 MB will be downloaded:
/gnu/store/m4qpxmn9v0jrylgbkzwssh5avzwhqil6-bash-minimal-5.0.16-doc
/gnu/store/fvhj74pghapbjvsvj27skvkra1by1965-bash-minimal-5.0.16
substituting /gnu/store/m4qpxmn9v0jrylgbkzwssh5avzwhqil6-bash-minimal-5.0.16-doc...
downloading from https://ci.guix.gnu.org/nar/lzip/m4qpxmn9v0jrylgbkzwssh5avzwhqil6-bash-minimal-5.0.16-doc ...
bash-minimal-5.0.16-doc 290KiB 444KiB/s 00:01 [##################] 100.0%

/gnu/store/vk4r0x7baig8jnmsqrgrqpyq8qxr4gm3-bash-5.0.16-doc
/gnu/store/v1xc4405s7xilmwhhkdj8z55wa2wlr8y-bash-5.0.16-include
/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16
/gnu/store/m4qpxmn9v0jrylgbkzwssh5avzwhqil6-bash-minimal-5.0.16-doc
/gnu/store/fvhj74pghapbjvsvj27skvkra1by1965-bash-minimal-5.0.16


Note that the manual is not updated since, since I do not know how to extend
the relevant section. Note also that "tests/guix-graph.sh" does not test any
of the backends.


All the best,
simon

zimoun (1):
guix: graph: Add 'plain' backend.

guix/graph.scm | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)


base-commit: 8d557d4167ea98dfbc200fd20f64b8da36da35a2
--
2.28.0
Z
Z
zimoun wrote on 17 Sep 2020 21:40
[PATCH 1/1] guix: graph: Add 'plain' backend.
(address . 43477@debbugs.gnu.org)(name . zimoun)(address . zimon.toutoune@gmail.com)
20200917194032.15103-1-zimon.toutoune@gmail.com
* guix/graph.scm: (emit-plain-prologue, emit-plain-epilogue, emit-plain-node,
emit-plain-edge): New procedures.
(%plain-backend): New variable.
(%graph-backends): Update variable.
---
guix/graph.scm | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)

Toggle diff (53 lines)
diff --git a/guix/graph.scm b/guix/graph.scm
index b695ca4306..4be864b29a 100644
--- a/guix/graph.scm
+++ b/guix/graph.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2015, 2016, 2020 Ludovic Courtès <ludo@gnu.org>
;;; Copyright © 2016 Ricardo Wurmus <rekado@elephly.net>
+;;; Copyright © 2020 Simon Tournier <zimon.toutoune@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -324,6 +325,28 @@ nodeArray.push(nodes[\"~a\"]);~%"
emit-cypher-prologue emit-cypher-epilogue
emit-cypher-node emit-cypher-edge))
+
+;;;
+;;; Plain export
+;;;
+
+(define (emit-plain-prologue name port)
+ (format port ""))
+
+(define (emit-plain-epilogue port)
+ (format port ""))
+
+(define (emit-plain-node id label port)
+ (format port "~a~%" label))
+
+(define (emit-plain-edge id1 id2 port)
+ (format port ""))
+
+(define %plain-backend
+ (graph-backend "plain"
+ "Generate Plain queries."
+ emit-plain-prologue emit-plain-epilogue
+ emit-plain-node emit-plain-edge))
;;;
@@ -333,7 +356,8 @@ nodeArray.push(nodes[\"~a\"]);~%"
(define %graph-backends
(list %graphviz-backend
%d3js-backend
- %cypher-backend))
+ %cypher-backend
+ %plain-backend))
(define* (export-graph sinks port
#:key
--
2.28.0
M
M
Mathieu Othacehe wrote on 18 Sep 2020 11:35
Re: [bug#43477] [PATCH 0/1] guix: graph: Add 'plain' backend.
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 43477@debbugs.gnu.org)
877dsr1l6s.fsf@gnu.org
Hello zimoun,

Toggle quote (6 lines)
> I am always annoyed when I use "guix graph" because most of the time I run:
>
> guix graph htop | grep label
>
> or something along these lines. Instead, the patch avoids the grep part:

What's your exact use case? Note that you can run something like:

Toggle snippet (3 lines)
guix gc -R `guix build htop`

to print the transitive closure of htop.

Toggle quote (19 lines)
> $ ./pre-inst-env guix graph -b plain htop
> htop@3.0.2
> autoconf@2.69
> perl@5.30.2
> m4@1.4.18
> automake@1.16.2
> autoconf-wrapper@2.69
> guile@2.0.14
> pkg-config@0.29.2
> libffi@3.3
> bash-minimal@5.0.16
> libunistring@0.9.10
> libltdl@2.4.6
> libgc@8.0.4
> gmp@6.2.0
> bash@5.0.16
> readline@8.0.4
> ncurses@6.2

The issue with this approach is that the output is not really a graph,
just a list of nodes.

Thanks,

Mathieu
R
R
Ricardo Wurmus wrote on 18 Sep 2020 14:34
(name . zimoun)(address . zimon.toutoune@gmail.com)
87v9gbtg9w.fsf@elephly.net
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (29 lines)
> Dear,
>
> I am always annoyed when I use "guix graph" because most of the time I run:
>
> guix graph htop | grep label
>
> or something along these lines. Instead, the patch avoids the grep part:
>
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix graph -b plain htop
> htop@3.0.2
> autoconf@2.69
> perl@5.30.2
> m4@1.4.18
> automake@1.16.2
> autoconf-wrapper@2.69
> guile@2.0.14
> pkg-config@0.29.2
> libffi@3.3
> bash-minimal@5.0.16
> libunistring@0.9.10
> libltdl@2.4.6
> libgc@8.0.4
> gmp@6.2.0
> bash@5.0.16
> readline@8.0.4
> ncurses@6.2
> --8<---------------cut here---------------end--------------->8---

Is that still a graph, though…?

It reminds me of “guix gc -R /gnu/store/…-something”, except that in
your case the output is for things that haven’t necessarily been
realized as store items yet.

--
Ricardo
Z
Z
zimoun wrote on 18 Sep 2020 21:59
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 43477@debbugs.gnu.org)
CAJ3okZ03hO0RjiDo=Jn_gkeB5MOe7r5MP4uKoFsorgcUNJp_UA@mail.gmail.com
Hi,

On Fri, 18 Sep 2020 at 11:36, Mathieu Othacehe <othacehe@gnu.org> wrote:

Toggle quote (14 lines)
> > I am always annoyed when I use "guix graph" because most of the time I run:
> >
> > guix graph htop | grep label
> >
> > or something along these lines. Instead, the patch avoids the grep part:
>
> What's your exact use case? Note that you can run something like:
>
> --8<---------------cut here---------------start------------->8---
> guix gc -R `guix build htop`
> --8<---------------cut here---------------end--------------->8---
>
> to print the transitive closure of htop.

Yes, but you do not have the granularity of the option '--type'.


Toggle quote (22 lines)
> > $ ./pre-inst-env guix graph -b plain htop
> > htop@3.0.2
> > autoconf@2.69
> > perl@5.30.2
> > m4@1.4.18
> > automake@1.16.2
> > autoconf-wrapper@2.69
> > guile@2.0.14
> > pkg-config@0.29.2
> > libffi@3.3
> > bash-minimal@5.0.16
> > libunistring@0.9.10
> > libltdl@2.4.6
> > libgc@8.0.4
> > gmp@6.2.0
> > bash@5.0.16
> > readline@8.0.4
> > ncurses@6.2
>
> The issue with this approach is that the output is not really a graph,
> just a list of nodes.

It is a flattened graph. :-)

Well, my use case is: I am doing "guix graph -t <something> | grep
label" and in general then "guix graph -t <other-thing> | grep label |
grep <package>"; which is not user friendly at all. And the output is
not friendly neither to pipe to other Guix commands.

The point is that "guix graph" is usually impractical in practise but
reads the plain "digraph" is not nice and pipe to "dot" produce
unmanageable PDF files.

Cheers,
simon
Z
Z
zimoun wrote on 18 Sep 2020 22:04
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ3okZ1iuN-we++1DRLDp-+2ijeMng2jDNRRmPz74gjdxDWfGg@mail.gmail.com
On Fri, 18 Sep 2020 at 14:33, Ricardo Wurmus <rekado@elephly.net> wrote:

Toggle quote (2 lines)
> Is that still a graph, though…?

I agree it is not a graph. Instead of 'plain' the name could be
'list-nodes', or whatever.


Toggle quote (4 lines)
> It reminds me of “guix gc -R /gnu/store/…-something”, except that in
> your case the output is for things that haven’t necessarily been
> realized as store items yet.

The point is that "guix gc" does not operate at the same level as "guix graph".

As I explained to Mathieu, my use case is: I am doing "guix graph -t
<something> | grep label" and in general then "guix graph -t
<other-thing> | grep label | grep <package>"; which is not user
friendly at all. The aim is to provide something where I can use for
example '-t bag'. And also something that I can use with the other
Guix commands.

Well, I have been annoyed a couple of times so I decided to fix my
issue and send a proposal. :-)

Cheers,
simon
L
L
Ludovic Courtès wrote on 24 Sep 2020 16:44
(name . zimoun)(address . zimon.toutoune@gmail.com)
87o8lv8cao.fsf@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (7 lines)
> On Fri, 18 Sep 2020 at 14:33, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> Is that still a graph, though…?
>
> I agree it is not a graph. Instead of 'plain' the name could be
> 'list-nodes', or whatever.

What would be super useful is a tree representation, like so:

guile
+ pkg-config
+ libgc
|- pkg-config […]
+ gmp
|- m4
+ libffi
+ bash-minimal

(With the right Unicode characters, of course. :-))

The trick here is to identify already-visited sub-graphs, like
pkg-config above, and to not repeat them (for example, add ellipses as
in the example above).

Thoughts?

Ludo’.
Z
Z
zimoun wrote on 24 Sep 2020 17:47
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ34BA9Q+9+b0T7vAJwN6ZgoVx_ceukn+iiV5eAvWpqLoQ@mail.gmail.com
Hi,

On Thu, 24 Sep 2020 at 16:44, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (5 lines)
> >> Is that still a graph, though…?
> >
> > I agree it is not a graph. Instead of 'plain' the name could be
> > 'list-nodes', or whatever.

The point is I am often doing

guix graph -t <type> <pkg> | grep label | grep <stuff>

then I select what I am interested in and reuse it with another Guix
command (size or graph again or show or whatever). And the regexp
directly pick the package name is too complicated to remember, so yes
I could have a script.

For example, I would to know if all the packages in my profile are OK
about CVE and already archived on SWH, with the proposed patch, it is
simply:

guix package -I | cut -f1 \
| xargs -I{} ./pre-inst-env guix graph -b list-nodes {} \
| xargs -I{} guix lint -c cve,archival {}

and obviously instead "-t bag" could be used.

Well, another option as "--list-nodes" could be added. WDTY?


Toggle quote (13 lines)
> What would be super useful is a tree representation, like so:
>
> guile
> + pkg-config
> + libgc
> |- pkg-config […]
> + gmp
> |- m4
> + libffi
> + bash-minimal
>
> (With the right Unicode characters, of course. :-))

It could be nice. And yeah, it will be the correct backend name: plain. :-)


All the best,
simon
L
L
Ludovic Courtès wrote on 25 Sep 2020 11:32
(name . zimoun)(address . zimon.toutoune@gmail.com)
87wo0i2odg.fsf@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (21 lines)
> The point is I am often doing
>
> guix graph -t <type> <pkg> | grep label | grep <stuff>
>
> then I select what I am interested in and reuse it with another Guix
> command (size or graph again or show or whatever). And the regexp
> directly pick the package name is too complicated to remember, so yes
> I could have a script.
>
> For example, I would to know if all the packages in my profile are OK
> about CVE and already archived on SWH, with the proposed patch, it is
> simply:
>
> guix package -I | cut -f1 \
> | xargs -I{} ./pre-inst-env guix graph -b list-nodes {} \
> | xargs -I{} guix lint -c cve,archival {}
>
> and obviously instead "-t bag" could be used.
>
> Well, another option as "--list-nodes" could be added. WDTY?

I think we should really focus on individual use cases and see how to
best address them. For example there’s
https://issues.guix.gnu.org/31442 that we could revisit now that we
have provenance metadata and inferiors. There’s also ‘guix size’, ‘guix
refresh -l’, and ‘guix graph --path’.

Perhaps we could have the backend you propose with the name ‘plain-flat’
(or similar), but I agree with Ricardo that it seems misplaced given
that it doesn’t show edges.

Thoughts?

Ludo’.
Z
Z
zimoun wrote on 25 Sep 2020 11:54
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ0AGeEuxtZR_YGLQqW2VBupsBQ5tXENbkwRZ6HmxHuZWA@mail.gmail.com
On Fri, 25 Sep 2020 at 11:32, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (17 lines)
> zimoun <zimon.toutoune@gmail.com> skribis:

> > For example, I would to know if all the packages in my profile are OK
> > about CVE and already archived on SWH, with the proposed patch, it is
> > simply:
> >
> > guix package -I | cut -f1 \
> > | xargs -I{} ./pre-inst-env guix graph -b list-nodes {} \
> > | xargs -I{} guix lint -c cve,archival {}
> >
> > and obviously instead "-t bag" could be used.
> >
> > Well, another option as "--list-nodes" could be added. WDTY?
>
> I think we should really focus on individual use cases and see how to
> best address them. For example there’s

I am not sure to understand. The aim of pipe composition is to build
bigger use cases reusing smaller units, right? (friday's trolling
inside ;-))

My individual use case is to list all the nodes of one package. And
by "all the nodes" I mean for all the kinds of graph types.

There is a "guix graph --path" which is really nice. Why not "guix
graph --list-nodes"?



Toggle quote (4 lines)
> https://issues.guix.gnu.org/31442 that we could revisit now that we
> have provenance metadata and inferiors. There’s also ‘guix size’, ‘guix
> refresh -l’, and ‘guix graph --path’.

The example above comes from this patch "guix health" that I commented
on [1]. :-)
Let's discuss that overthere.



Toggle quote (4 lines)
> Perhaps we could have the backend you propose with the name ‘plain-flat’
> (or similar), but I agree with Ricardo that it seems misplaced given
> that it doesn’t show edges.

I understand. The addition of a backend is not appropriate and
confusing (except the plain you backend you proposed).
Therefore, my proposal is to add another option to "guix graph":

guix graph --list-nodes

similarly to "--path". Except that "guix graph --list-nodes -t bag"
will show all the nodes of the bag graph.


WDYT?

All the best,
simon
R
R
Ricardo Wurmus wrote on 25 Sep 2020 12:11
(name . zimoun)(address . zimon.toutoune@gmail.com)
87o8luf9nh.fsf@elephly.net
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (28 lines)
> On Fri, 25 Sep 2020 at 11:32, Ludovic Courtès <ludo@gnu.org> wrote:
>> zimoun <zimon.toutoune@gmail.com> skribis:
>
>> > For example, I would to know if all the packages in my profile are OK
>> > about CVE and already archived on SWH, with the proposed patch, it is
>> > simply:
>> >
>> > guix package -I | cut -f1 \
>> > | xargs -I{} ./pre-inst-env guix graph -b list-nodes {} \
>> > | xargs -I{} guix lint -c cve,archival {}
>> >
>> > and obviously instead "-t bag" could be used.
>> >
>> > Well, another option as "--list-nodes" could be added. WDTY?
>>
>> I think we should really focus on individual use cases and see how to
>> best address them. For example there’s
>
> I am not sure to understand. The aim of pipe composition is to build
> bigger use cases reusing smaller units, right? (friday's trolling
> inside ;-))
>
> My individual use case is to list all the nodes of one package. And
> by "all the nodes" I mean for all the kinds of graph types.
>
> There is a "guix graph --path" which is really nice. Why not "guix
> graph --list-nodes"?

Wouldn’t the tree view that Ludo proposed match your use case? You can
still grep the output (filtering non-alphanum characters), but it would
be more useful by default.

--
Ricardo
Z
Z
zimoun wrote on 25 Sep 2020 14:22
Guix aliases? (was: [bug#43477] [PATCH 0/1] guix: graph: Add 'plain' backend.)
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ3okZ0QAtfH-tXdnG+nywCOny+-USFaacWGckzD8zJW7wo9MA@mail.gmail.com
On Fri, 25 Sep 2020 at 12:10, Ricardo Wurmus <rekado@elephly.net> wrote:

Toggle quote (7 lines)
> > There is a "guix graph --path" which is really nice. Why not "guix
> > graph --list-nodes"?
>
> Wouldn’t the tree view that Ludo proposed match your use case? You can
> still grep the output (filtering non-alphanum characters), but it would
> be more useful by default.

I would say no. :-) You are proposing:

guix graph -b ludo-backend | tr -dc '\0-\177'

right? I will never remember that. So it means I would have a script
wrapper, somehow; and in this case, instead a AWK wrapper around the
graphviz backend could already do the job.

Well, it remembers the discussion here [1].



My understanding of this situation:

1- specific "guix graph" case: implement something like Ludo
proposed; "--backend plain" in the meaning of non-graphical or
terminal displayable backend.
2- add a mechanism to have aliases.

The #1 is low priority to me. Let's expand explanations about the #2.
Now with "guix repl", the user can extend Guix by their own scripts.
Therefore, it could be nice:

a) to have a location by default (say ~/.config/guix/scripts)
b) to run them with "guix foo" instead of "guix repl --
~/.config/guix/scripts/foo.scm"

And then, we can all be happy. ;-)
It eases the tests of new experimental command-line tools, I can
locally change the behaviour of "guix environment --ad-hoc", I can
experiment with new output formats for "guix search" instead of
recutils, etc.. Well, the philosophy of custom extensions.

WDYT?

All the best,
simon
L
L
Ludovic Courtès wrote on 25 Sep 2020 17:56
Re: Guix aliases?
(name . zimoun)(address . zimon.toutoune@gmail.com)
878scxkfyd.fsf@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (15 lines)
> On Fri, 25 Sep 2020 at 12:10, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> > There is a "guix graph --path" which is really nice. Why not "guix
>> > graph --list-nodes"?
>>
>> Wouldn’t the tree view that Ludo proposed match your use case? You can
>> still grep the output (filtering non-alphanum characters), but it would
>> be more useful by default.
>
> I would say no. :-) You are proposing:
>
> guix graph -b ludo-backend | tr -dc '\0-\177'
>
> right?

I don’t think so. The tree view would be a way to visualize the graph,
first and foremost.

What I meant to say was that, if we have other use cases, we can write
new commands or extend existing ones to cater to those needs. That’s
how ‘guix size’, etc. came to life. “Listing nodes” is not a use case
per se, but rather an means to an end; let’s focus on the ends. :-)

(Also, let’s avoid Unix arguments; the primary composition level in Guix
is Scheme, not byte streams on stdout.)

Toggle quote (2 lines)
> 2- add a mechanism to have aliases.

I agree it’d be nice but… we’re drifting off-topic. :-)

Thanks,
Ludo’.
Z
Z
zimoun wrote on 25 Sep 2020 19:00
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ3wVYRF7RSUELSEwgb6uaPt6B5zyas1CWaMC8mcMamY=A@mail.gmail.com
On Fri, 25 Sep 2020 at 17:56, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (8 lines)
> What I meant to say was that, if we have other use cases, we can write
> new commands or extend existing ones to cater to those needs. That’s
> how ‘guix size’, etc. came to life. “Listing nodes” is not a use case
> per se, but rather an means to an end; let’s focus on the ends. :-)
>
> (Also, let’s avoid Unix arguments; the primary composition level in Guix
> is Scheme, not byte streams on stdout.)

Well, I am not sure yet if I agree or disagree with you. :-)
I understand the arguments and I will not have time to write a v2
which includes your suggestion; I am interested in listing the nodes
for some ends, not by visualizing the graph in a non-X environment.
Therefore, feel free to close this patch submission.

Cheers,
simon
L
L
Ludovic Courtès wrote on 5 Oct 2020 10:03
Re: [bug#43477] Guix aliases?
(name . zimoun)(address . zimon.toutoune@gmail.com)
87tuv95cc5.fsf@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (16 lines)
> On Fri, 25 Sep 2020 at 17:56, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> What I meant to say was that, if we have other use cases, we can write
>> new commands or extend existing ones to cater to those needs. That’s
>> how ‘guix size’, etc. came to life. “Listing nodes” is not a use case
>> per se, but rather an means to an end; let’s focus on the ends. :-)
>>
>> (Also, let’s avoid Unix arguments; the primary composition level in Guix
>> is Scheme, not byte streams on stdout.)
>
> Well, I am not sure yet if I agree or disagree with you. :-)
> I understand the arguments and I will not have time to write a v2
> which includes your suggestion; I am interested in listing the nodes
> for some ends, not by visualizing the graph in a non-X environment.
> Therefore, feel free to close this patch submission.

OK so I’m closing for now, but let’s reopen an issue if you or someone
else thinks we really need a list-node feature or something along these
lines.

Thanks,
Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 43477@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 43477
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch