Hi Ludo, Christopher wrote this:
>>> I'm not particularly fond of the implementation, because the >>> package-derivation function is called from expand-input called from >>> bag->derivation, the information about the part of the graph that has >>> been traversed is passed through each function. >>> >>> The seen-package-list argument could be removed, but the ordering >>> information is really useful when printing out the error message. I >>> think it should be still possible to generate this after finding the >>> issue by searching through the graph of packages, which would allow >>> removing this one argument. >>> >>> One other thought I had is that this could be extracted to something in >>> guix lint, which would at least allow finding these problems, without >>> touching the core derivation related code. I wrote this: >> I’d be in favour of keeping it out of the core and stash it away in a >> separate tool. Not sure if that should be “guix lint” (what about “guix >> graph”?), but I would prefer that over having the code run all the time. And you wrote that: > I’d be in favor of keeping it in the core, like Chris did, provided the > code is not too complex and provided there’s no significant performance > penalty. That way, problems would always be gracefully handled. When the planned package cache feature is implemented, the performance penalty would only apply when the cache is invalid, so I think it may not be a problem. I’d love to see this patch or a variant of it make it into the master branch. -- Ricardo
