From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: Store channel specification in profile Date: Sat, 08 Feb 2020 18:09:44 +0100 Message-ID: <8736bldmzr.fsf@ambrevar.xyz> 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> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:57627) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j0Tc6-0001YX-Sa for guix-devel@gnu.org; Sat, 08 Feb 2020 12:09:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j0Tc5-0004C1-5b for guix-devel@gnu.org; Sat, 08 Feb 2020 12:09:50 -0500 In-Reply-To: <87pneq140d.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-mx.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Guix Devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Turns out I just watched your talk (since I couldn=E2=80=99t be there at = the > time!). I was surprised you didn=E2=80=99t explicitly mention =E2=80=98g= uix search=E2=80=99 and > the shortcomings you=E2=80=99d like to address (well, not directly), but = I liked > the perspectives! I guess I took "guix search" for granted and assumed everyone knew what I was talking about :p > 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 futur= e-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 discus= s such > things! Indeed, because we were on the same page all along: my "keyed code snippet" was about the serialization format, not the data structure! So agreed on all points here. > =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 ha= ndle 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? > I agree that =E2=80=98--export=E2=80=99 is less convenient. Note that = =E2=80=98guix system > reconfigure=E2=80=99 does exactly what you have in mind: it stores a > =E2=80=98channels.scm=E2=80=99 and a =E2=80=98config.scm=E2=80=99 file in= the system (in addition to > serialized & versioned metadata in the =E2=80=98provenance=E2=80=99 file)= because that=E2=80=99s > so convenient: > > guix time-machine -C /run/current-system/channels.scm -- > system build --save-provenance -C /run/current-system/configuration.s= cm Nice example, thanks for sharing. > But in this case it=E2=80=99s OK: =E2=80=98channels.scm=E2=80=99 uses a t= iny teeny subset of the > API, and =E2=80=98configuration.scm=E2=80=99 is evaluated in the right co= ntext where the > APIs it expects are available. > > Does that make sense? > > We cannot do the same thing with profiles because of the possibly > multiple provenances. With the serialization I proposed, the provenance is serialize per-package. Do you think it would still be a problem? > 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? If so, we could re-use a given version of Guix to apply the transformation. Maybe too sophisticated for what it's worth. > All I=E2=80=99m saying is that we can only approximate all these things. > Because of that, it may make more sense to not over-engineer the thing > and focus on making a rough approximation. Absolutely. > After all, the goal of the functionality we=E2=80=99re discussing is to a= llow > users to move towards the declarative =E2=80=98manifest.scm=E2=80=99 styl= e, 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". Cheers! =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl4+61gACgkQm9z0l6S7 zH8rEwgArRJZHW5NGHv0jE8uDDvv5Nms3wK/45WgzCqoyWIiINPy0bqPEtTSTIAy h3oJgpQqTlM+gFO1PT5o7AZu4YebMrd9xCItjLfmL+71pZa4b2JXI6QL3E0BT3k1 iMD8aJsAMVa8GX1LdsOMibTa3zPsIrWNt18+WdXO+yhbEj1RU3S42NSUsdwt/K0N 8JVo/E6hwtDiOHja97VE3x4wRWJusuNcrVg5NM9dxoXhHUWGl+bo55PPB0FZlkB3 15PgwByL85AyJRPoybtYdabP92RmNshZXb77je+W2ay+gPwQ2FAPkr9vGooWxRjD K215quMT3J+YGFsdZW5EZ1bBTkml+g== =5OeQ -----END PGP SIGNATURE----- --=-=-=--