In the code there, the function propagate-packages will indeed try and propagate every package through the graph node.
I looked at your code, it's comprehensive. I wasn't sure such a thing was possible with input rewriting, although I think there's still a lot of benefit to the functional approach, like this:
- some packages are present under different names (emacs has emacs-minimal, emacs, emacs-pgtk, emacs-wide-int...) and that is not handled by this function.
It should handle it pretty elegantly, since those packages inherit from emacs, if you replace emacs they'll inherit from your replacement while keeping their unique traits.
- propagating some packages that are used in build-systems will trigger massive rebuilds (e.g. go, emacs, python, ocaml, texlive), you'll probably have to be smart about what you want to avoid to propagate, but it's great because guix can already hide a package to package-inputs-rewriting using (hidden-package {package-name}). There are some examples in the series.
No idea how, but I guess I should implement a #:mask-hidden? argument to handle this. I have more basic issues for now, but that's a good point.
- this has a cost. I haven't timed it yet, but the slowdown is noticeable, though still quite usable.
I'm doing a couple stupid things, it's improved with the last few commits, but there's still a long way to go. If there's a cost to syntax rule abuse, you were probably feeling that.
- you of course have to get the packages into the function from a profile. Here's it's done in RDE's code, but that should be quite doable in Guix too.
Yeah, the implementation model is kinda strange. Having to put extra code in every single module in the entire repo isn't a great prerequisite for anything. It could be the point that prevents this from manifesting. The mile long butt-ugly list of inputs that it needs doesn't help. Thanks for the tips. Work is still ongoing, but recursive propagation now works when giving one package-set another as an input, so the intended use-case is now possible. - sc