From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Composing service definitions (and maybe fmt) Date: Sun, 24 Jan 2016 21:35:17 +0100 Message-ID: <87twm2lnqy.fsf@gnu.org> References: <87oacloy61.fsf@dustycloud.org> <87fuxt5zh9.fsf@dustycloud.org> <87vb6ogmqw.fsf@dustycloud.org> <87si1rx5l4.fsf@gnu.org> <87zivyvd0u.fsf@gnu.org> <87bn8e4m9a.fsf@dustycloud.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]:50762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNRNc-0006zx-Id for guix-devel@gnu.org; Sun, 24 Jan 2016 15:35:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNRNZ-0001XQ-BY for guix-devel@gnu.org; Sun, 24 Jan 2016 15:35:24 -0500 In-Reply-To: <87bn8e4m9a.fsf@dustycloud.org> (Christopher Allan Webber's message of "Thu, 21 Jan 2016 13:57:18 -0800") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Christopher Allan Webber Cc: guix-devel Christopher Allan Webber skribis: > You may remember my post to the list about how I'm interested in > service configurations which know about each others' variables. I wrote > about why I think this is really important to solving deployment here: > > http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00736.html > > If we build procedures which go from procedure inputs -> text and that's > all that gets passed to the service, do we lose the ability to > introspect the arguments being used to set up the service? Not necessarily: object have a =E2=80=98parameters=E2=80=99 field= to hold the service=E2=80=99s arguments, and this can always be introspected and manipulated. It=E2=80=99s just that there=E2=80=99s a =E2=80=9Cpreferred form=E2=80=9D t= o manipulate these service parameters. For instance, a high-level struct is easy to deal with, an argument list is OK but less convenient, and a file-like object is pretty bad. > Would it be possible to have services which themselves set up services? > Eg, imagine I had something imaginary like: > > (3dprinter-service > #:model "lawlsbot-3000" > #:fill-pattern "hex") > > (Ignore whether or not this is a sane way to configure a 3d printer at > all at the moment, I'm just making something up) > > So, this might actually build the "implied" service of: > > (3dprinter-raw-service > "[printconfig] > model =3D lawlsbot-3000 > fill-pattern =3D hex") > > ... this way, daring users can provide their own config file if our > config file builders aren't good enough, but it's still possible to > have some other service or tool read that the 3dprinter-service has a > model with lawlsbot-3000, so it can show it in a menu, or something. > > Is this possible, or even sane? :) So you=E2=80=99re suggesting to systematically have a high-level interface = as well as a lower-level interface that gives access to the raw config file, right? The problem is that often, the service configuration does not to just one config file. Often it also translates into command-line options, user accounts, etc. For instance, =E2=80=98tor-service=E2=80=99 expects us= ers to pass a raw config file, but it also needs to create a user account whose name is given in that config file, so it needs to control that part of the config file. That being said, it=E2=80=99s always possible to extend =E2=80=98etc-servic= e-type=E2=80=99 and give it raw config files. Not offering any concrete solution but=E2=80=A6 does that make sense? :-) Thanks, Ludo=E2=80=99.