Hey there! Ludovic Courtès <l...@gnu.org> skribis:
> Ludovic Courtès <ludovic.cour...@inria.fr> skribis: > >> Indeed, evaluating: >> >> (bag-transitive-inputs >> (package->bag ((package-input-rewriting '()) glib))) >> >> shows that we have two “python” packages there that are not ‘eq?’. > > The problem is that ‘glib’ depends on ‘python-libxml2’, which uses > ‘python-build-system’ and thus has ‘python’ as an implicit input. > > ‘package-input-rewriting’ doesn’t touch implicit inputs so it leaves > that implicit ‘python’ untouched. > > Since ‘transitive-inputs’ (used by ‘bag-transitive-inputs’) uses pointer > equality, we end up with two “python” packages that are not ‘eq?’ but > are functionally equivalent: the one produced by > ‘package-input-rewriting’, and the implicit dependency of > ‘python-libxml2’. QED. > > (This is essentially the same as <https://bugs.gnu.org/30155>.) Good news, this is fixed by 2bf6f962b91123b0474c0f7123cd17efe7f09a66, which introduces package rewriting including implicit inputs! Before getting there, this issue did get on my nerves for a while. Here are several ways to address this issue that I thought of: 1. Have ‘package-input-rewriting/spec’ traverse implicit inputs, at least optionally. We wouldn’t end up with an equivalent-but-not-eq? ‘python’ in the example above. It does change the semantics though, and it may be nice to keep a “shallow” replacement option. That’s what 2bf6f962b91123b0474c0f7123cd17efe7f09a66 does. 2. Do (delete-duplicates input-drvs) in ‘bag->derivation’. That seems wise, but it’s unfortunately impossible on ‘master’ because of <https://issues.guix.gnu.org/43508>. 3. ‘package-input-rewriting/spec’ preserves eq?-ness for packages not transformed; in the example above, the transformation result would be eq? to ‘glib’ because ‘--with-input=libreoffice=inkscape’ had no effect. Tricky to implement efficiently, perhaps not worth it. I think #2 might still be worth investigating, but it may have undesirable implications too. #3 is hardly doable. All in all, I’m glad that #1 addresses the issue, because it’s also something we wanted anyway. Ludo’.
