From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: [PATCH 3/7] import cran: description->package: Also return package dependencies. Date: Wed, 31 Aug 2016 12:39:33 +0200 Message-ID: References: <1464018008-1767-1-git-send-email-ricardo.wurmus@mdc-berlin.de> <1464018008-1767-4-git-send-email-ricardo.wurmus@mdc-berlin.de> <87d1o49bdr.fsf@gnu.org> <87h9a31u1d.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]:52717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bf2vs-0007fP-0H for guix-devel@gnu.org; Wed, 31 Aug 2016 06:39:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bf2vl-0001eU-VU for guix-devel@gnu.org; Wed, 31 Aug 2016 06:39:46 -0400 In-Reply-To: <87h9a31u1d.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 Ludovic Court=C3=A8s writes: > Ricardo Wurmus skribis: > >> Ricardo Wurmus writes: >> >>> Ludovic Court=C3=A8s writes: >>> >>>> Ricardo Wurmus skribis: >>>> >>>>> * guix/import/cran.scm (description->package): Return package >>>>> dependencies in addition to generated package expression. >>>> >>>> What would you think of making it return a SRFI-41 stream of package= s >>>> instead? Or maybe two values: the package asked for, and the stream >>>> containing its dependencies. That would hide the package lookup >>>> machinery. >>> >>> That=E2=80=99s a very good idea! I=E2=80=99ll play around with this = and submit a new >>> patch. >> >> I=E2=80=99ve been playing with this for a while and although it looks = prettier >> to a user it has some disadvantages to use streams here. The first is >> that it becomes more difficult to avoid duplicate work. The second is >> that we can no longer easily generate an order of package expressions >> from leaf nodes to the root. >> >> Consider this case where =E2=80=9Cplotly=E2=80=9D should be imported. = The new inputs >> look like this: >> >> plotly : (ggplot2 digest) >> ggplot2 : (digest mass) >> digest : () >> mass : () >> >> The generated stream may look like this: >> >> (plotly ggplot2 digest mass digest) >> >> This happens because we only know about the next set of inputs upon >> evaluation of the stream elements. Of course there are ways to fix >> this, but they involve extending or wrapping =E2=80=9Ccran->guix-packa= ge=E2=80=9D to >> make sure that we keep track of top-level dependencies as we traverse >> the list of dependencies recursively. >> >> Maybe I=E2=80=99m doing this wrong? >> >> >> I rewrote description->package to essentially do this: >> >> (stream-cons the-package-expression >> (stream-concat >> (let ((unpackaged (unpackaged-dependencies >> propagate guix-name))) >> (stream-map (cran->guix-package name repository) >> (list->stream unpackaged))))) >> >> I.e. the first element of the stream is the imported package expressio= n; >> the tail is a concatenation of streams of packages with their >> dependencies just like this one. Here=E2=80=99s the stream before >> concatenation: >> >> (plotly (ggplot2 (digest ()) (mass ())) >> (digest ())) >> >> To render this in the correct order we=E2=80=99d have to turn this tre= e inside >> out. Maybe this isn=E2=80=99t so well-suited to a representation as a= stream >> after all. To turn it inside out we have to evaluate the whole tree >> anyway. >> >> What do you think? Is it worth expressing this as a stream? If so, d= o >> you have any recommendations on how to approach this? >> >> Or would it be okay to let =E2=80=9Cdescription->package=E2=80=9D retu= rn two values: a >> package expression and a list of unpackaged package names, which can >> then be processed by a separate procedure? (That=E2=80=99s what I sub= mitted >> earlier.) > > I think you should go ahead with what you proposed if the other option > sounds like a headache. Sorry for blocking you for this long! No problem. I would really like to use streams, so it=E2=80=99s worth th= e wait. Can=E2=80=99t avoid the headache :) > In theory it would be possible to do something like: > > (define (description->package repo meta) > (stream-cons `(package =E2=80=A6) > (stream-unfold (lambda (state) > (description->package > repo > (first-dependency state))) > (lambda (state) > (done? state)) > (lambda (state) > (next-dependency state)) > (make-state propagate (setq))))) > > =E2=80=A6 where the state is roughly a pair containing the list of next > dependencies and the set of already visited dependencies (to avoid > duplicates). That=E2=80=99s a good hint. =E2=80=9Cstream-unfold=E2=80=9D makes my hea= d spin, to be honest. > But again, this is probably easier said than done, so no problem with > keeping the initial option. I=E2=80=99ll read the documentation for =E2=80=9Cstream-unfold=E2=80=9D a= gain and try once more. If I really cannot make it I=E2=80=99ll go ahead with the initial implementation and submit a new patch set. ~~ Ricardo