From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Package input loop detection Date: Wed, 18 Apr 2018 10:58:51 +0200 Message-ID: <87k1t4evqs.fsf@elephly.net> References: <87eflzfkwh.fsf@cbaines.net> <87fu66kyxn.fsf@elephly.net> <87po57u3io.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8tws-0002Uu-AX for guix-devel@gnu.org; Wed, 18 Apr 2018 16:45:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f8twp-00031P-BH for guix-devel@gnu.org; Wed, 18 Apr 2018 16:45:02 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21012) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f8twp-000315-2U for guix-devel@gnu.org; Wed, 18 Apr 2018 16:44:59 -0400 In-reply-to: <87po57u3io.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org 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=E2=80=99d be in favour of keeping it out of the core and stash it away= in a >> separate tool. Not sure if that should be =E2=80=9Cguix lint=E2=80=9D (= what about =E2=80=9Cguix >> graph=E2=80=9D?), but I would prefer that over having the code run all t= he time. And you wrote that: > I=E2=80=99d be in favor of keeping it in the core, like Chris did, provid= ed the > code is not too complex and provided there=E2=80=99s no significant perfo= rmance > 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=E2=80=99d love to see this patch or a variant of it make it into the mast= er branch. -- Ricardo