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: Fri, 07 Feb 2020 22:28:18 +0100 Message-ID: <87pneq140d.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> 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]:41292) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j0BAl-0003eI-Dy for guix-devel@gnu.org; Fri, 07 Feb 2020 16:28:24 -0500 In-Reply-To: <87eev8gewx.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Thu, 06 Feb 2020 11:59:10 +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! 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=98gui= x search=E2=80=99 and the shortcomings you=E2=80=99d like to address (well, not directly), but I = liked the perspectives! https://video.fosdem.org/2020/AW1.125/gnuguixpackagemanager.webm Pierre Neidhardt skribis: >> One thing to keep in mind, though, is that if the =E2=80=98specification= s.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. I feel there a Common Lisp vs. Scheme cultural clash here. ;-) The way I see it, a public procedure should take clearly defined, structured objects, and of only a single type (that=E2=80=99s a pattern mos= tly followed throughout Guix). So, if I were to implement the proposed =E2=80=98specifications->manifest*= =E2=80=99, it would take a record to describe the package/version/channel. But then that record wouldn=E2=80=99t be different from a referenci= ng an . IOW: the API already exists, mostly. I would not use sexps (like the one you propose) as substitutes for records in an API. I know that=E2=80=99s the traditional Lisp way to do it= , but it=E2=80=99s IMO too clumsy, error-prone (unless you use a pattern matcher,= but even then it=E2=80=99s not enough), inefficient, etc. 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 future-= 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 discuss = such things! >> 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 directl= y 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. =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 hand= le 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. >> 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 = then again, that means >> relying on a larger chunk of the API. > > I'm not sure I understood what you meant here. Which APIs? =E2=80=98specification->package=E2=80=99 is part of the API. >> 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 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 t= he system (in addition to serialized & versioned metadata in the =E2=80=98provenance=E2=80=99 file) b= ecause that=E2=80=99s so convenient: guix time-machine -C /run/current-system/channels.scm -- system build --save-provenance -C /run/current-system/configuration.scm But in this case it=E2=80=99s OK: =E2=80=98channels.scm=E2=80=99 uses a tin= y teeny subset of the API, and =E2=80=98configuration.scm=E2=80=99 is evaluated in the right cont= ext 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. >> 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? 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. >> and we lack information about arbitrary user code that might have been >> used to generate manifest entries. > > Is this a problem? 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. After all, the goal of the functionality we=E2=80=99re discussing is to all= ow users to move towards the declarative =E2=80=98manifest.scm=E2=80=99 style,= right? Thanks, Ludo=E2=80=99.