Re: Package input loop detection

[Ricardo Wurmus <rekado@elephly.net>]

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