From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: Package input loop detection Date: Mon, 12 Feb 2018 19:48:59 +0100 Message-ID: References: <87eflzfkwh.fsf@cbaines.net> <87fu66kyxn.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045d99eebf2a7e05650854ee" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elJ9y-0007xE-Cj for guix-devel@gnu.org; Mon, 12 Feb 2018 13:49:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elJ9w-0005Rd-H4 for guix-devel@gnu.org; Mon, 12 Feb 2018 13:49:02 -0500 Received: from mail-it0-x233.google.com ([2607:f8b0:4001:c0b::233]:37449) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1elJ9w-0005Pr-96 for guix-devel@gnu.org; Mon, 12 Feb 2018 13:49:00 -0500 Received: by mail-it0-x233.google.com with SMTP id d10so1798280itj.2 for ; Mon, 12 Feb 2018 10:49:00 -0800 (PST) In-Reply-To: <87fu66kyxn.fsf@elephly.net> 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: Ricardo Wurmus Cc: Guix-devel --f403045d99eebf2a7e05650854ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-02-12 16:30 GMT+01:00 Ricardo Wurmus : > > Hi, > > > I've had this issue for a while now, while adding some packages, I'll > > create a loop in the package graph, which causes Guix to just loop > > infinitely when trying to generate derivations. > > this is a great initiative. I=E2=80=99ve been having this issue in the p= ast as > well, and I=E2=80=99d really like Guix to be a little smarter about it. > > I also welcome this idea. > > 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=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 (w= hat about =E2=80=9Cguix > graph=E2=80=9D?), but I would prefer that over having the code run all th= e time. > > I feel that "guix graph" is a good suggestion. Correct me if I'm mistaken, but it seems to me that we currently traverse our graph breadth first. For this functionality a depth first traversal would have benefits. Could be extended to topologically short the whole DAG. WDYT? > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > > --f403045d99eebf2a7e05650854ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -02-12 16:30 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:=

Hi,

> I've had this issue for a while now, while adding some packages, I= 'll
> create a loop in the package graph, which causes Guix to just loop
> infinitely when trying to generate derivations.

this is a great initiative.=C2=A0 I=E2=80=99ve been having this issu= e in the past as
well, and I=E2=80=99d really like Guix to be a little smarter about it.


I also welcome= this idea.
=C2=A0
> 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 h= as
> 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 i= n
> guix lint, which would at least allow finding these problems, without<= br> > touching the core derivation related code.

I=E2=80=99d be in favour of keeping it out of the core and stash it = away in a
separate tool.=C2=A0 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 the = time.


I feel that "guix graph" is = a good suggestion.
Correct me if I'm mistaken, but it seems t= o me that we currently traverse
our graph breadth first. For this= functionality a depth first traversal would have
benefits. Could= be extended to topologically short the whole DAG. WDYT?
=C2=A0
--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC
https:= //elephly.net




--f403045d99eebf2a7e05650854ee--