| Message ID | 20200917193931.14699-1-zimon.toutoune@gmail.com |
|---|---|
| Headers | show |
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
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.
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
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
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
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’.
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
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.
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
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’.
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
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’.