From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Store channel specification in profile Date: Wed, 8 Jan 2020 20:31:16 +0100 Message-ID: References: <87blsyelgm.fsf@ambrevar.xyz> <87tv69bezo.fsf@gnu.org> <87zhg1xvmo.fsf@ambrevar.xyz> <874kx8gxh1.fsf@ambrevar.xyz> <87blreasgd.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56330) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipH3E-00018b-IN for guix-devel@gnu.org; Wed, 08 Jan 2020 14:31:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipH3D-0007pq-Df for guix-devel@gnu.org; Wed, 08 Jan 2020 14:31:32 -0500 In-Reply-To: <87blreasgd.fsf@ambrevar.xyz> 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 Hi Pierre, On Wed, 8 Jan 2020 at 16:17, Pierre Neidhardt wrote: > > a. keep the file /manifest as it is today; and add > > options to convert it to regular manifests and channels. > > b. improve the format of this file to obtain consistent manifests. > > > > and c. improve what the --manifest option accepts. > > Agreed. > > > From my perspective, the option b. is a better path because it remove > > layers and complexity. > > I thought you meant "do all 3 options". How would option b. alone be enough? I agree and I am on this wavelength. Maybe we had some noise in previous emails. :-) > >> Should we not change the format, should we add a command line option to > >> convert manifest to "manifest specifications" (those that work with > >> `-manifest')? How do we include the provenance in manifest specifications? > > > > The provenance of what? > > How do we include the "provenance" field from manifest into "manifest > specifications"? I read "channel" instead of "provenance". > > Basically an entry looks like: > > > > --8<---------------cut here---------------start------------->8--- > > ("diffoscope" > > "131" > > "out" > > "/gnu/store/h8zr4rxhvpikv9p07kdjkf2dsrja35wm-diffoscope-131" > > (propagated-inputs ()) > > (search-paths ()) > > (properties > > (provenance > > (repository > > (version 0) > > (url "https://git.savannah.gnu.org/git/guix.git") > > (branch "master") > > (commit > > "b5d4d5b9bcf267fddd02fcc14b88eac0bebf979f"))))) > > --8<---------------cut here---------------end--------------->8--- > > The above is not very human friendly. Each entry should be something > like plist with default values, so that the user does not have to write > "out" every time. > > What about this: > > ("diffoscope" > :version "131" > :output "doc" ; "out" is the default. > :provenance (repository ...)) > > Questions: > > - Do manifests really need the store path? I do not see why neither. Maybe in this scenario: you build a profile with --manifest=foo.scm, then you send me this foo.scm manifest file and /manifest. With these, I instantiate a profile with --manifest=foo.scm and I can "challenge" against what you have by comparing my hashes to your hashes. > - Same question about propagated-inputs. Aren't they already encoded in > the package definition? Why repeating them here? I agree. All the best, simon