Björn Höfling transcribed 74K bytes: > Hi Guix, > > we have this nice `guix graph` tool which outputs DAGs of the packages > (or even derivations,bags, ...). This is cool if you look at simple > packages like the "hello" package with little to no dependencies. If > you look at "real" packages like qt or maven the information is just > overwhelming and you are scrolling around the image for just getting a > headache. > > Often the only think I want to know is something like: Why is "goodbye" > a dependency of "hello"? > > To answer this, I want to extract from hello's package graph the path > (more precisely: the sub-DAG) leading from the root "hello" to the > target node (or even nodes) "goodbye". > > After several attempts and failures, I wrote a script for gvpr from > the GraphViz suite that does the job. > > Example 1: In bug #30710 Hartmut Goebel asked why qt depends on two > different autoconf-wrapper packages. To answer that, you can find out > the two node names from the .dot file and then call: > > gvpr -f markpath.g -a "ex 64168128 64167936" < qt-thing/qt.package.dot > >qt-acw.dot > > This extracts (ex) the path (sub-DAG) to the two seed nodes and outputs > it in a new graph. This result is quite compact with only 12 nodes (attached). > > Example 2: How/Why is glib a dependency of maven? The extracted graph > has about 50 nodes, so I don't attach it here. You will see that > java-logback-classic depends on a groovy-cluster that finally mounts > into antlr. That depends on a gtk/pango/cairo-cluster that finally > sinks into glib. > > Hope that is useful to someone else, > > Björn > >
To add to this idea: abyayala$ nix why-depends --help Usage: nix why-depends <FLAGS>... <PACKAGE> <DEPENDENCY> Summary: show why a package has another package in its closure. Flags: -a, --all show all edges in the dependency graph leading from 'package' to 'dependency', rather than just a shortest path --arg <NAME> <EXPR> argument to be passed to Nix functions --argstr <NAME> <STRING> string-valued argument to be passed to Nix functions -f, --file <FILE> evaluate FILE rather than the default -I, --include <PATH> add a path to the list of locations used to look up <...> file names Examples: To show one path through the dependency graph leading from Hello to Glibc: $ nix why-depends nixpkgs.hello nixpkgs.glibc To show all files and paths in the dependency graph leading from Thunderbird to libX11: $ nix why-depends --all nixpkgs.thunderbird nixpkgs.xorg.libX11 To show why Glibc depends on itself: $ nix why-depends nixpkgs.glibc nixpkgs.glibc Note: this program is EXPERIMENTAL and subject to change. Would it be useful to have a guix package subcommand which replicates this?