| Message ID | 20200509230401.28364-1-ludo@gnu.org |
|---|---|
| Headers | show |
On Sun, 10 May 2020 at 18:18, zimoun <zimon.toutoune@gmail.com> wrote: > > ‘guix graph --path emacs libffi | xargs guix show’ > > > > Though ‘guix show’ appears to ignore all but one argument, uh. > > Yes. Because it is a pure alias of "guix package --show='. To be more explicit, it is because 'process-query' processes only one query. Which makes sense in the context of "guix package", e.g., "guix package --show=emacs --search=libffi" will be a bad idea, IMHO. BUt not necessary "guix package --show=emacs --show=libffi". I do not know,. There is an easy fix in 'guix/scripts/show.scm': (map (lambda opt (guix-package* opt)) (reverse opts)) but I am thinking if something better is possible to fix "--show=emacs --show=libffi" too. Cheers, simon
Hi Ludo, > ‘guix graph --path emacs libffi | xargs guix show’ > > Though ‘guix show’ appears to ignore all but one argument, uh. Just to let you know that the patch [1] should fix the issue. Now "--show" is processed as "--search" and so piping works. [1] issues.guix.gnu.org/41183 Cheers, simon
zimoun <zimon.toutoune@gmail.com> skribis: > On Sun, 10 May 2020 at 18:18, zimoun <zimon.toutoune@gmail.com> wrote: > >> > ‘guix graph --path emacs libffi | xargs guix show’ >> > >> > Though ‘guix show’ appears to ignore all but one argument, uh. >> >> Yes. Because it is a pure alias of "guix package --show='. > > To be more explicit, it is because 'process-query' processes only one > query. Which makes sense in the context of "guix package", e.g., > "guix package --show=emacs --search=libffi" will be a bad idea, IMHO. > BUt not necessary "guix package --show=emacs --show=libffi". I do not > know,. > > There is an easy fix in 'guix/scripts/show.scm': > > (map (lambda opt (guix-package* opt)) (reverse opts)) > > but I am thinking if something better is possible to fix "--show=emacs > --show=libffi" too. Let’s discuss it and above all fix it in a separate thread! :-) Ludo’.
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > ./pre-inst-env guix graph --path -t references libreoffice llvm > guix graph: error: no path from > '/gnu/store/rd24gl402vy5g5sm3azhq13mwdg5fbi1-libreoffice-6.4.2.2' to > '/gnu/store/bcgnx704v408sr7lcy480wcnbkcixwrw-llvm-10.0.0-opt-viewer' There’s a path to llvm@9 though. Such examples will of course bitrot over time because they depend on the dependency graph, which keeps changing. But that’s OK IMO: the goal is just to give an idea of what the tool can do. >> wording proposal in mind that is as concise? > > display the shortest path from node1 to node2 ‘node1’ and ‘node2’ are undefined though… >> As for ‘--path-to’ instead of ‘--path’: I think a path in common >> language is directed (one follows a path from one place to another). > > My english is probably not enough good. (Note that is the same for me > with the french word "chemin".) > To me, "path" is often ambiguous because sometimes it means oriented > and sometimes not; depending on the context: topology, graph theory, > common life: synonymous of road or track and synonymous of route or > direction. > > This ambiguity added to the non positional option '--path' appears to > me confusing from where to where. > > My 2 remarks come from this ambiguity of the word "path". > Well, maybe it is only me. I don’t know, but I’m still unconvinced that ‘--path-to’ is any better than ‘--path’. In the end, the intended audience consists of people who know we’re talking about a DAG. Thanks for your feedback! Ludo’.
On Mon, 11 May 2020 at 14:36, Ludovic Courtès <ludo@gnu.org> wrote: > zimoun <zimon.toutoune@gmail.com> skribis: > > > ./pre-inst-env guix graph --path -t references libreoffice llvm > > guix graph: error: no path from > > '/gnu/store/rd24gl402vy5g5sm3azhq13mwdg5fbi1-libreoffice-6.4.2.2' to > > '/gnu/store/bcgnx704v408sr7lcy480wcnbkcixwrw-llvm-10.0.0-opt-viewer' > > There’s a path to llvm@9 though. Well, I do not know if the issue is not about the "outputs" 'out' vs 'opt-viewer'. I probably do not understand how 'references' works but 'dbus' is an 'inputs' of 'vlc' and: ./pre-inst-env guix graph --path vlc -t references dbus guix graph: error: no path from '/gnu/store/2qk6h97bhm5zii59005ws5qk6drhdp3b-vlc-3.0.10' to '/gnu/store/6a65in084gfn5bbgyna179irhghvqfpy-dbus-1.12.16-doc' Cheers, simon
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > On Mon, 11 May 2020 at 14:36, Ludovic Courtès <ludo@gnu.org> wrote: > >> zimoun <zimon.toutoune@gmail.com> skribis: >> >> > ./pre-inst-env guix graph --path -t references libreoffice llvm >> > guix graph: error: no path from >> > '/gnu/store/rd24gl402vy5g5sm3azhq13mwdg5fbi1-libreoffice-6.4.2.2' to >> > '/gnu/store/bcgnx704v408sr7lcy480wcnbkcixwrw-llvm-10.0.0-opt-viewer' >> >> There’s a path to llvm@9 though. > > Well, I do not know if the issue is not about the "outputs" 'out' vs > 'opt-viewer'. I probably do not understand how 'references' works but > 'dbus' is an 'inputs' of 'vlc' and: > > ./pre-inst-env guix graph --path vlc -t references dbus > guix graph: error: no path from > '/gnu/store/2qk6h97bhm5zii59005ws5qk6drhdp3b-vlc-3.0.10' to > '/gnu/store/6a65in084gfn5bbgyna179irhghvqfpy-dbus-1.12.16-doc' You’re doing it right, but the ‘dbus’ package has two outputs and the thing just picks the first one, which is not the one you’re interested in. I’ll check if we can just arrange to parse outputs instead of packages. Thanks, Ludo’.
I pushed the whole series: 88a96c568c guix graph: Add '--path'. 36c2192414 graph: Add 'shortest-path'. 7240202136 graph: reference/referrer node types work with graph traversal. Ludo’.
Hi Ludo, On Mon, 11 May 2020 at 22:55, Ludovic Courtès <ludo@gnu.org> wrote: > You’re doing it right, but the ‘dbus’ package has two outputs and the > thing just picks the first one, which is not the one you’re interested > in. Yes, my point is: the example "libreoffice --path llvm" does not work because of that. Not because llvm@9 vs llvm@10, I guess. :-) I have tried to find another example without several outputs but did not find one complex enough to be "interesting"; that's why the most simple 'vlc' and 'dbus'. :-) There is always an output (doc or debug or etc.) which breaks '--path -t references'. Well, I am not sure to understand how it works for 'references' because I miss how several outputs are managed: same key, two values. And from my understanding, the last value (doc or debug or etc. and generally not out) replaces any other. Cheers, simon