From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Channel dependencies Date: Mon, 22 Oct 2018 14:14:08 +0200 Message-ID: <87lg6qmb5b.fsf@gnu.org> References: <877eimnxpq.fsf@mdc-berlin.de> <87pnwbim2q.fsf@gnu.org> <87tvljknpb.fsf@mdc-berlin.de> 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]:59993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEZ64-0002ws-9I for guix-devel@gnu.org; Mon, 22 Oct 2018 08:14:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEZ63-0001FR-CZ for guix-devel@gnu.org; Mon, 22 Oct 2018 08:14:12 -0400 In-Reply-To: <87tvljknpb.fsf@mdc-berlin.de> (Ricardo Wurmus's message of "Thu, 18 Oct 2018 22:24:32 +0200") 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@gnu.org Hello! Ricardo Wurmus skribis: >> I=E2=80=99d recommend =E2=80=98match=E2=80=99 for the outer sexp, and th= en something like the >> =E2=80=98alist-let*=E2=80=99 macro from (gnu services herd) in places wh= ere you=E2=80=99d like >> to leave field ordering unspecified. > > I keep forgetting about alist-let* (from srfi-2, not herd), even though > it=E2=80=99s so useful! =E2=80=9Cchannel-instance-dependencies=E2=80=9D = now uses the > record via =E2=80=9Cread-channel-metadata=E2=80=9D and= uses match. Heck I didn=E2=80=99t even know about SRFI-2. :-) >> Then I think it would make sense to add the =E2=80=98dependencies=E2=80= =99 field to >> directly (and keep internal.) >> Each element of the =E2=80=98dependencies=E2=80=99 field would be another >> . >> >> Actually =E2=80=98dependencies=E2=80=99 could be a promise that reads ch= annel meta-data >> and looks up the channel instances for the given dependencies. >> Something like that. > > This sounds good, but I don=E2=80=99t know how to make it work well, beca= use > there=E2=80=99s a circular relationship here if we want to keep the abstr= actions > pretty. I can=E2=80=99t simply define the =E2=80=9Cdependencies=E2=80=9D= field of > to have a default thunked procedure like this: > > (match (read-channel-metadata checkout) > (#f '()) > (($ _ dependencies) > dependencies)) > > Because record fields cannot access other record fields such as > =E2=80=9Ccheckout=E2=80=9D. This makes the code look rather silly as we= =E2=80=99re creating an > instance with an explicit dependencies value only to read it from that > same record in the next expression. > > In light of these complications I=E2=80=99d prefer to have a procedure > =E2=80=9Cchannel-instance-dependencies=E2=80=9D that handles this for us,= and do without > a =E2=80=9Cdependencies=E2=80=9D field on the record. > > What do you think? Sure, that makes sense to me (sometimes I throw ideas that look great on paper but simply don=E2=80=99t fly in practice!). > From e23225640e723988de215d110e377c93c8108245 Mon Sep 17 00:00:00 2001 > From: Ricardo Wurmus > Date: Sat, 13 Oct 2018 08:39:23 +0200 > Subject: [PATCH] guix: Add support for channel dependencies. > > * guix/channels.scm (): New record. > (read-channel-metadata, channel-instance-dependencies): New procedures. > (latest-channel-instances): Include channel dependencies; add optional > argument PREVIOUS-CHANNELS. > (channel-instance-derivations): Build derivation for additional channels = and > add it as dependency to the channel instance derivation. > * doc/guix.texi (Channels): Add subsection "Declaring Channel Dependencie= s". [...] > + ;; Accumulate a list of instances. A list of processed channels is al= so > + ;; accumulated to decide on duplicate channel specifications. > + (match (fold (lambda (channel acc) > + (match acc > + ((#:channels previous-channels #:instances instances) > + (if (ignore? channel previous-channels) > + acc > + (begin > + (format (current-error-port) > + (G_ "Updating channel '~a' from Git re= pository at '~a'...~%") > + (channel-name channel) > + (channel-url channel)) > + (let-values (((checkout commit) > + (latest-repository-commit store = (channel-url channel) > + #:ref = (channel-reference > + = channel)))) > + (let ((instance (channel-instance channel co= mmit checkout))) > + (let-values (((new-instances new-channels) > + (latest-channel-instances > + store > + (channel-instance-dependenc= ies instance) > + previous-channels))) > + `(#:channels > + ,(append (cons channel new-channels) > + previous-channels) > + #:instances > + ,(append (cons instance new-instances) > + instances)))))))))) > + `(#:channels ,previous-channels #:instances ()) > + channels) This seems to be assuming that CHANNELS is topologically-sorted, is that right? Otherwise LGTM. There=E2=80=99s the conflict error reporting mentioned in another message t= hat I think we could implement, but that can come later. Also we should consider adding unit tests for at least some of this; I plaid guilty for not having provided a test strategy from the start. Thank you, and apologies for not replying on time for your presentation! Ludo=E2=80=99.