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

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

[zimoun]

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---


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

--8<---------------cut here---------------start------------->8---
$ 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
--8<---------------cut here---------------end--------------->8---


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

[bug#43477] [PATCH 1/1] guix: graph: Add 'plain' backend.

[zimoun]

* 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(-)

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))
 
+\f
+;;;
+;;; 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))
 
 \f
 ;;;
@@ -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

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

[Mathieu Othacehe]

Hello zimoun,

> 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.

> $ ./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

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

[Ricardo Wurmus]

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

> 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

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

[zimoun]

Hi,

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

> > 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'.


> > $ ./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

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

[zimoun]

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.


> 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

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

[Ludovic Courtès]

Hi,

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

> 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’.

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

[zimoun]

Hi,

On Thu, 24 Sep 2020 at 16:44, Ludovic Courtès <ludo@gnu.org> 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.

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?


> 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

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

[Ludovic Courtès]

Hi,

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

> 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’.

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

[zimoun]

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"?



> <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.

[1] <https://issues.guix.gnu.org/31442#9>


> 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

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

[Ricardo Wurmus]

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

> 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

[bug#43477] Guix aliases? (was: [bug#43477] [PATCH 0/1] guix: graph: Add 'plain' backend.)

[zimoun]

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 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].

[1] <https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00358.html>


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

[bug#43477] Guix aliases?

[Ludovic Courtès]

Hi,

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

> 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.)

>  2- add a mechanism to have aliases.

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

Thanks,
Ludo’.

[bug#43477] Guix aliases?

[zimoun]

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.

Cheers,
simon

bug#43477: Guix aliases?

[Ludovic Courtès]

Hi,

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

> 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’.