Hello, Hartmut Goebel <h.goe...@crazy-compilers.com> skribis:
>> This is expected. Strictly speaking, we’re talking about two different >> package objects, hence the different IDs. > > I wonder > > a) whether it is useful to have different graph nodes for the same package. > > This is about usability of the resulting graph, esp. since this is the > default graph output format. Does it help *users* for their analysis? Or > is this some *expert* insight? As explained in “Invoking guix graph”, the tool provides different graph types, each at its own abstraction level. The package graph is high-level, but as a side-effect it has this artifact. To developers it’s actually useful to see the graph of package objects. There are cases where, with functions that return packages, you would notice that you’re generating lots of package objects for the same underlying derivation, which is super inefficient (in particular it defeats memoization). Most of the time, there’s exactly one package object for each derivation; if not, that’s usually a bug. > b) how there can be different package objects for the same package > > To my understanding, e.g. (gnu packages base) is loaded once, defining > package object abcd once and assigning it to a variable. All packages > referring to abcd use the some package object. So there should be only > *one* package object. (eq? foo (package (inherit foo))) => #false Yet, these two packages map to the very same derivation. HTH, Ludo’.
