Re: New ‘guix graph’ command
Cyril Roelandt skribis: > On 08/27/2015 12:53 AM, Ludovic Courtès wrote: >> Here’s a long overdue ‘guix graph’ command (documentation below.) >> Comments welcome! > > Would it be hard to do the opposite of what guix graph does ? I'd like > to be able to find the list of packages which depend on a given package. > This would be useful when updating a package, to make sure that the > update does not break anything. It shouldn’t be too hard, using something akin to the code of ‘guix refresh --list-dependent’. Ludo’.
Re: New ‘guix graph’ command
I think that is what `guix gc --referrers /gnu/store/...package` does. http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-gc.html On Thu, Sep 10, 2015, at 20:02, Cyril Roelandt wrote: > On 08/27/2015 12:53 AM, Ludovic Courtès wrote: > > Here’s a long overdue ‘guix graph’ command (documentation below.) > > Comments welcome! > > Would it be hard to do the opposite of what guix graph does ? I'd like > to be able to find the list of packages which depend on a given package. > This would be useful when updating a package, to make sure that the > update does not break anything. > > WDYT? > > > Cyril. >
Re: New ‘guix graph’ command
On 08/27/2015 12:53 AM, Ludovic Courtès wrote: > Here’s a long overdue ‘guix graph’ command (documentation below.) > Comments welcome! Would it be hard to do the opposite of what guix graph does ? I'd like to be able to find the list of packages which depend on a given package. This would be useful when updating a package, to make sure that the update does not break anything. WDYT? Cyril.
Re: New ‘guix graph’ command
On Fri, Sep 04, 2015 at 10:13:01AM +0200, Pjotr Prins wrote: > Maybe we should have both. Well, there is no real need for two versions; if most people like things as they are, they should stay as they are. Andreas
Re: New ‘guix graph’ command
Maybe we should have both. I like the current version because it reads logically from a *users* perspective. E.g. http://dthompson.us/images/guix/ruby-pg-graph.png ruby-pg depends on postgresql 9.3.8, depends on zlib 1.2.7. Logical. Pj. On Thu, Sep 03, 2015 at 08:55:46PM +, Cook, Malcolm wrote: > Hi, > > I like the request. > > I think the dependent packages should be pointed to. > > In this way, each node in the graph and its outgoing arrows reflect the > contents of a single package. > > ~Malco > > > -Original Message- > > From: guix-devel-bounces+mec=stowers@gnu.org [mailto:guix-devel- > > bounces+mec=stowers@gnu.org] On Behalf Of Ludovic Courtès > > Sent: Thursday, September 03, 2015 3:47 PM > > To: Andreas Enge > > Cc: Guix-devel > > Subject: Re: New ‘guix graph’ command > > > > Hey! > > > > Andreas Enge skribis: > > > > > Very neat indeed! A tiny bit of nitpicking: Would it not be preferable > > > if the arrows were reversed, from the inputs to the dependent packages? > > > > Dunno, maybe the graph people would choose the other direction but I like > it > > this way, looks more “intuitive” to me. What do people think? > > > > Ludo’. > --
RE: New ‘guix graph’ command
Hi, I like the request. I think the dependent packages should be pointed to. In this way, each node in the graph and its outgoing arrows reflect the contents of a single package. ~Malco > -Original Message- > From: guix-devel-bounces+mec=stowers@gnu.org [mailto:guix-devel- > bounces+mec=stowers@gnu.org] On Behalf Of Ludovic Courtès > Sent: Thursday, September 03, 2015 3:47 PM > To: Andreas Enge > Cc: Guix-devel > Subject: Re: New ‘guix graph’ command > > Hey! > > Andreas Enge skribis: > > > Very neat indeed! A tiny bit of nitpicking: Would it not be preferable > > if the arrows were reversed, from the inputs to the dependent packages? > > Dunno, maybe the graph people would choose the other direction but I like it > this way, looks more “intuitive” to me. What do people think? > > Ludo’.
Re: New ‘guix graph’ command
On Thu, Sep 3, 2015 at 4:46 PM, Ludovic Courtès wrote: > Hey! > > Andreas Enge skribis: > >> Very neat indeed! A tiny bit of nitpicking: Would it not be preferable if >> the arrows were reversed, from the inputs to the dependent packages? > > Dunno, maybe the graph people would choose the other direction but I > like it this way, looks more “intuitive” to me. What do people think? I prefer it the way that it is because it reflects the actual data structure. It's intuitive because I often ask "what does this software depend on?", not "what depends on this software?" - Dave
Re: New ‘guix graph’ command
Hey! Andreas Enge skribis: > Very neat indeed! A tiny bit of nitpicking: Would it not be preferable if > the arrows were reversed, from the inputs to the dependent packages? Dunno, maybe the graph people would choose the other direction but I like it this way, looks more “intuitive” to me. What do people think? Ludo’.
Re: New ‘guix graph’ command
Hello! On Thu, Aug 27, 2015 at 12:53:03AM +0200, Ludovic Courtès wrote: > Here’s a long overdue ‘guix graph’ command (documentation below.) > Comments welcome! Very neat indeed! A tiny bit of nitpicking: Would it not be preferable if the arrows were reversed, from the inputs to the dependent packages? Andreas
Re: New ‘guix graph’ command
On Thu, Aug 27, 2015 at 4:55 PM, Ludovic Courtès wrote: > "Thompson, David" skribis: > >> Just one question: I see that when using the 'references' type, each >> node in the graph has an arrow pointing to itself. Is that >> intentional? > > It’s not really “each node” but rather “most nodes.” :-) > > The daemon keeps track of all the references of each item, including > self-references. And it turns out that most packages record their > $prefix in their binaries, for instance, hence the self-reference. This > can be seen with ‘guix gc --references’ as well. That makes sense. Thanks for the explanation! - Dave
Re: New ‘guix graph’ command
"Thompson, David" skribis: > Just one question: I see that when using the 'references' type, each > node in the graph has an arrow pointing to itself. Is that > intentional? It’s not really “each node” but rather “most nodes.” :-) The daemon keeps track of all the references of each item, including self-references. And it turns out that most packages record their $prefix in their binaries, for instance, hence the self-reference. This can be seen with ‘guix gc --references’ as well. Ludo’.
Re: New ‘guix graph’ command
On Wed, Aug 26, 2015 at 6:53 PM, Ludovic Courtès wrote: > Hi! > > Here’s a long overdue ‘guix graph’ command (documentation below.) > Comments welcome! This is awesome! I think it will prove to be a really helpful tool for understanding the relationships between packages and discovering issues like packages that have references to build-time dependencies. Just one question: I see that when using the 'references' type, each node in the graph has an arrow pointing to itself. Is that intentional? Thanks for the awesome new tool! - Dave
Re: New ‘guix graph’ command
Ludovic Courtès (2015-08-27 01:53 +0300) wrote: > Here’s a long overdue ‘guix graph’ command (documentation below.) > Comments welcome! This is really cool! Thank you! -- Alex
Re: New ‘guix graph’ command
Mathieu Lirzin skribis: > Nice job, It is really convenient to have such utility. > > Does it sound feasible to produce different edge colors depending of the type > of inputs? Of course! But this is left as an exercise to the reader. :-) Similarly, I thought we could use different color boxes based on the size of a store item, for the ‘references’ DAGs. It “just needs” adding an attribute argument to the ‘emit-node’ and ‘emit-edges’ hooks of . I don’t plan to work on it in the near future but would definitely welcome patches. > Not really important, but IMO it would be clearer to define bag-emerged > in terms of what bag is doing with something like this. > > ‘bag’ > This is the package DAG, _including_ implicit inputs. > > ‘bag-emerged’ > > Similar to ‘bag’, but this time without all the bootstrap > dependencies. > > For instance, the following command: > > guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf > > [...] > > What do you think? Perhaps this isn’t very clear but I wanted to list the graph types in order of increasing complexity, which is why ‘bag’ comes after ‘bag-emerged’. Dunno if something needs to be changed; thoughts? Thanks, Ludo’.
Re: New ‘guix graph’ command
Nice job, It is really convenient to have such utility. Does it sound feasible to produce different edge colors depending of the type of inputs? l...@gnu.org (Ludovic Courtès) writes: > ‘bag-emerged’ > This is the package DAG, _including_ implicit inputs. > > For instance, the following command: > > guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf > > ... yields this bigger graph: > > > > At the bottom of the graph, we see all the implicit inputs of > GNU-BUILD-SYSTEM (*note ‘gnu-build-system’: Build Systems.). > > Now, note that the dependencies of those implicit inputs—that is, > the “bootstrap dependencies” (*note Bootstrapping::)—are not shown > here, for conciseness. > > ‘bag’ > Similar to ‘bag-emerged’, but this time including all the bootstrap > dependencies. Not really important, but IMO it would be clearer to define bag-emerged in terms of what bag is doing with something like this. --8<---cut here---start->8--- ‘bag’ This is the package DAG, _including_ implicit inputs. ‘bag-emerged’ Similar to ‘bag’, but this time without all the bootstrap dependencies. For instance, the following command: guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf [...] --8<---cut here---end--->8--- What do you think? -- Mathieu Lirzin
Re: New ‘guix graph’ command
Very useful! On Thu, Aug 27, 2015 at 12:53:03AM +0200, Ludovic Courtès wrote: > Hi! > > Here’s a long overdue ‘guix graph’ command (documentation below.) > Comments welcome! > > Ludo’.
