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: Wed, 05 Feb 2020 12:08:58 +0100 Message-ID: <87wo91p9yt.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> 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]:48179) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izIYI-0004yn-L4 for guix-devel@gnu.org; Wed, 05 Feb 2020 06:09:04 -0500 In-Reply-To: <87zhe4px2a.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Thu, 30 Jan 2020 20:24:13 +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 Hello! Pierre Neidhardt skribis: > Ideas that are not that good on second thought: > > - Create a profile specification file from CLI options, > like --export PROFILE or --convert MANIFEST. > > The problem is that those are extra steps that the user would have to r= un > manually. We can save those extra steps by dumping the specification f= ile > automatically into the profile. > > The Plan=C2=A9: > > On every profile installation, we generate a "specifications.scm" file al= ongside > the internal "manifest". One thing to keep in mind, though, is that if the =E2=80=98specifications.s= cm=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 ve= ry strong constraint. 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 u= sable from the CLI. > Problems: > > - There may be too many provenances, we need to add a CLI flag to > ignore provenance. Like Konrad wrote, just write if there are too many of them. > Proposed format for "specifications.scm": we can reuse > `specifications->manifest`. Each entry is either or string, in which cas= e 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 must= 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. 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 the= n again, that means relying on a larger chunk of the API. So, all in all, I think I=E2=80=99d rather see it implemented as =E2=80=98g= uix package --export=E2=80=99 or similar. The generated Scheme file could use all the = parts of the current API (and we could adjust the generator as we change the API). So it could generate something similar to the example in the manual (info "(guix) Inferiors"): --8<---------------cut here---------------start------------->8--- (use-modules (guix inferior) (guix channels) (srfi srfi-1)) ;for 'first' (define channels ;; This is the old revision from which we want to ;; extract guile-json. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) (define inferior ;; An inferior representing the above revision. (inferior-for-channels channels)) ;; Now create a manifest with the current "guile" package ;; and the old "guile-json" package. (packages->manifest (list (first (lookup-inferior-packages inferior "guile-json")) (specification->package "guile"))) --8<---------------cut here---------------end--------------->8--- There could also be an option to generate a =E2=80=9Csymbolic=E2=80=9D mani= fest: one that would install packages of the same name, but not resorting to inferiors. The result would not be a faithful translation of what=E2=80=99s actually in the store, but an approximation thereof that could be useful for people transitioning. In fact it would be easier to start by prototyping this before going further. 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), and we lack information about arbitrary user code that might have been used to generate manifest entries. Thus, as we design this, I think we must keep in mind that the result is necessarily an approximation. > A somewhat unrelated propostion: To avoid further confusion between the i= nternal > "manifest" and the user-facing "--manifest", we could rename the internal > manifest to $profile/internal-maifest. Renaming =E2=80=98manifest=E2=80=99 is not really an option because, as we = discussed, it=E2=80=99s a contract over time: today=E2=80=99s Guix can interact with a= profile created 5 years ago just fine. Thanks for sharing your thoughts! Ludo=E2=80=99.