[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Package input loop detection
From: |
Ricardo Wurmus |
Subject: |
Re: Package input loop detection |
Date: |
Wed, 18 Apr 2018 10:58:51 +0200 |
User-agent: |
mu4e 1.0; emacs 25.3.1 |
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
- Re: Package input loop detection,
Ricardo Wurmus <=