From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Store channel specification in profile Date: Tue, 11 Feb 2020 15:10:13 +0100 Message-ID: <87zhdp2p16.fsf@gnu.org> References: <87blsyelgm.fsf@ambrevar.xyz> <87tv69bezo.fsf@gnu.org> <87zhg1xvmo.fsf@ambrevar.xyz> <874kx8gxh1.fsf@ambrevar.xyz> <87blreasgd.fsf@ambrevar.xyz> <87pnfpsgfx.fsf@gnu.org> <87a76rqu5j.fsf@ambrevar.xyz> <877e1vqowd.fsf@ambrevar.xyz> <87zhe4px2a.fsf@ambrevar.xyz> <87wo91p9yt.fsf@gnu.org> <87eev8gewx.fsf@ambrevar.xyz> <87pneq140d.fsf@gnu.org> <8736bldmzr.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47355) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j1WEz-0001tt-S2 for guix-devel@gnu.org; Tue, 11 Feb 2020 09:10:18 -0500 In-Reply-To: <8736bldmzr.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sat, 08 Feb 2020 18:09:44 +0100") 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-mx.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix Devel Howdy! Pierre Neidhardt skribis: > Ludovic Court=C3=A8s writes: [...] >> I would, however, use sexps as a serialization format. Compared to an >> API, an object serialized to an sexp has the advantage that we can write >> code to handle changes in the serialization format, so it=E2=80=99s futu= re-proof >> if we get it right. But then: we=E2=80=99re back to =E2=80=98manifest= =E2=80=99. :-) >> >> I hope this is a bit clearer, but I realize it=E2=80=99s tricky to discu= ss such >> things! > > Indeed, because we were on the same page all along: my "keyed code snippe= t" > was about the serialization format, not the data structure! Good. >> =E2=80=98manifest=E2=80=99 looks like this: >> >> (manifest >> (version 3) >> =E2=80=A6) >> >> We have an explicit =E2=80=98read-manifest=E2=80=99 procedure that can h= andle version 3, >> but also prior versions, and this is all transparent. >> >> You cannot do that with code. Code is just evaluated, and if it=E2=80= =99s >> incompatible, if fails in some unspecified way. > > Same thing, what I had in mind was to store the version number in the > _serialized_ specifications.scm, as for the manifest. > > This way I believe we can support multiple version for specifications.scm. > Am I missing something? Then I don=E2=80=99t get how =E2=80=98specifications.scm=E2=80=99 would dif= fer from =E2=80=98manifest=E2=80=99. In both cases we=E2=80=99re talking about a serialization format containing per-package provenance info, right? >> We could store package transformations as manifest entry properties. >> >> However, that=E2=80=99ll be an approximation: the exact implementation of >> =E2=80=98--with-input=E2=80=99, for instance, can vary over time. > > Hmmm, even if we have the provenance? Yes. >> After all, the goal of the functionality we=E2=80=99re discussing is to = allow >> users to move towards the declarative =E2=80=98manifest.scm=E2=80=99 sty= le, right? > > Yes, so I'll try to sum up what I want to achieve in one sentence: > "automate the textual serialization of profile specifications to > simplify their backup/deployment/reproduction". OK. To me, serialization is already automated: it=E2=80=99s the =E2=80=98manife= st=E2=80=99 file. What we lack is the ability to obtain a =E2=80=9Cmanifest.scm=E2=80=9D kind= of file (code) that users can pick as a starting point in their migration towards declarative deployment. Does that make sense? Am I paraphrasing you correctly? :-) Thanks, Ludo=E2=80=99.