From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Neidhardt Subject: Re: Store channel specification in profile Date: Thu, 06 Feb 2020 11:59:10 +0100 Message-ID: <87eev8gewx.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> 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]:51406) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izesO-0003ai-QO for guix-devel@gnu.org; Thu, 06 Feb 2020 05:59:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izesM-0006Dt-Ls for guix-devel@gnu.org; Thu, 06 Feb 2020 05:59:16 -0500 In-Reply-To: <87wo91p9yt.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 Hi! Ludovic Court=C3=A8s writes: > Hello! > >> The Plan=C2=A9: >> >> On every profile installation, we generate a "specifications.scm" file a= longside >> the internal "manifest". > > One thing to keep in mind, though, is that if the =E2=80=98specifications= .scm=E2=80=99 > is part of the profile, it must be future-proof. That is, the APIs it > uses must essentially be guaranteed to remain forever. That=E2=80=99s a = very > strong constraint. I think that's OK. In the example format I suggested, we use keys, which make it easy to extend the format later on, if need be. > In contrast, versioned data formats like the famous =E2=80=98manifest=E2= =80=99 file > don=E2=80=99t have this problem at all, but they=E2=80=99re less directly= usable from > the CLI. We can version the specifications.scm as well. Can you explain what the problem is, I think I'm missing the point. >> Proposed format for "specifications.scm": we can reuse >> `specifications->manifest`. Each entry is either or string, in which ca= se it >> acts as before, or a list, with the following self-explanatory elements: >> >> (specifications->manifest >> '(("my-package" >> #:outputs '("out") >> #:version "2.3" >> #:channel (channel >> (name 'guix) >> (branch "master") >> (url "https://git.savannah.gnu.org/git/guix.git") >> (commit >> "704719edade1368f798c9301f3a8197a0df5c930"))) >> ("my-package2") >> "old-style-package")) > > As a rule of thumb, I think =E2=80=98specifications->manifest=E2=80=99 mu= st remain what > it is: it should take a specification as is currently defined and return > a manifest. I think that if we need a new concept, we should not > overload an existing one. In my understanding it's not so much of a new concept as an extension of the existing one. But defining a new function is not a problem at all either. What about specifications->manifest* ? > We also need to distinguish between APIs, which should use first-class > objects (, etc.), and data formats, which are plain sexps. > (The above example is a mixture of both and in fact looks very similar > to what=E2=80=99s already in the =E2=80=98manifest=E2=80=99 file.) But t= hen again, that means > relying on a larger chunk of the API. I'm not sure I understood what you meant here. Which APIs? > So, all in all, I think I=E2=80=99d rather see it implemented as =E2=80= =98guix package > --export=E2=80=99 or similar. I think I didn't understand why you'd prefer to have a command instead of systematically generating the file inside the profile. Or maybe we could generate the file somewhere else if that's the problem? In my opinion, the `--export` approach would be cumbersome because it means that for users who want to save the specifications file, they'd need to systematically call it on every profile-modifying command, e.g. guix package -m manifest.scm && guix package --export > There could also be an option to generate a =E2=80=9Csymbolic=E2=80=9D ma= nifest: one > that would install packages of the same name, but not resorting to > inferiors. I think this can be implemented with the --use-default-channels option I suggested before. > As far as faithfulness is concerned, we should also keep in mind that we > don=E2=80=99t always have all the information needed to reconstruct what= =E2=80=99s in a > profile. For example, we lack information about the package > transformation options that were used (if any), Like `--with-input'? I didn't think of this. Can't we extend the format then to include all transformation options, with future-proof provisions? Example: =2D-8<---------------cut here---------------start------------->8--- (specifications->manifest '(("my-package" #:outputs '("out") #:version "2.3" #:transformation '((input PACKAGE REPLACEMENT) (source SOURCE)) #:channel (channel (name 'guix) (branch "master") (url "https://git.savannah.gnu.org/git/guix.git") (commit "704719edade1368f798c9301f3a8197a0df5c930"))) =2D-8<---------------cut here---------------end--------------->8--- > and we lack information about arbitrary user code that might have been > used to generate manifest entries. Is this a problem? Even if we only store generated manifest entries, this should be enough to reproduce the profile, no? =2D-=20 Pierre Neidhardt https://ambrevar.xyz/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl478X4ACgkQm9z0l6S7 zH8vQAgAg/RWZ2RibFkSO0ESgkdJhSavA2j0MMjJOvNsKyIPD7MsDUiSvl/x6tUg B96ygfYzPlm0jpt+EwcigfCIJOZnniPXJhfkxGFco0KEgYQ9QB5PXIMOMCGSfunJ BzwQTM6izdWsi/hu/7GHA1DEsWi80R7lxcwu07Dj4igV2RkcD5hmVtV8oV9nKypo Z2tl32DYlwmt+QnNgB8tHoyDV90LALImpK55T+A4oYJCQdMo/M8c7PcEiOEWNUrp STTYFXFLZ0XL2jJNXy/klTQUILG6drnPs8HhkxM4OPWwS4NiKcvo3qlns6Hx77n6 UGake/HDBnr6O87Z5GAoT1uIw0Y12g== =GyVN -----END PGP SIGNATURE----- --=-=-=--