From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id KGTfG85n6V7yagAA0tVLHw (envelope-from ) for ; Wed, 17 Jun 2020 00:46:06 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GFi0F85n6V4CKwAAbx9fmQ (envelope-from ) for ; Wed, 17 Jun 2020 00:46:06 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id ABEE39404D3 for ; Wed, 17 Jun 2020 00:46:05 +0000 (UTC) Received: from localhost ([::1]:39922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jlMDM-0007Eg-FQ for larch@yhetil.org; Tue, 16 Jun 2020 20:46:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jlMD9-0007CI-V2 for guix-devel@gnu.org; Tue, 16 Jun 2020 20:45:51 -0400 Received: from m42-5.mailgun.net ([69.72.42.5]:40752) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jlMD6-0004Tr-5B for guix-devel@gnu.org; Tue, 16 Jun 2020 20:45:51 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.wilsonb.com; q=dns/txt; s=krs; t=1592354749; h=Content-Type: MIME-Version: Message-Id: In-Reply-To: References: Subject: From: Cc: To: Date: Sender; bh=svvkyNJFRmfaM/OF0O2/vND5FS7Q0B1y53usHRnMKGU=; b=ds6NPJOU/xn6IOP14paLYWG43jfsXTY+KJsUxpY6xMUTPARDzOH4w3IhMsEN1s/eSjax3L9k cN96TV3A0FU2EnuDJ6EerEyU9a7UgBInRLHscXeUjZ2Ge3qj/o3o39gPguNjKpFpv6R9mJnv I4zlj8ES+7z5qAdR+OMYxO5cwRfW7Z9OsdeAIP1iTNEqpEQqpVrrE+Rc9fF4kFWLwIo5dnRH aBT2jATx6upwpGjZd7hd/bVpii3gS5WeiLxTh+qwhN72QwJ7+Pw+xplq1f8XGFVRngnYi+MQ EHkoUa/ZZ9kQv+VqvuiufoHa/B9K0eFGo7st2Vp7EEf3zeoVn42jNQ== X-Mailgun-Sending-Ip: 69.72.42.5 X-Mailgun-Sid: WyIyNWJlMSIsICJndWl4LWRldmVsQGdudS5vcmciLCAiMDg1NDdhIl0= Received: from wilsonb.com (wilsonb.com [104.199.203.42]) by smtp-out-n02.prod.us-west-2.postgun.com with SMTP id 5ee967b43a8a8b20b8a92e99 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Wed, 17 Jun 2020 00:45:40 GMT Received: from localhost (KD111239206180.au-net.ne.jp [111.239.206.180]) by wilsonb.com (Postfix) with ESMTPSA id 03D77A2B24; Wed, 17 Jun 2020 00:45:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wilsonb.com; s=201703; t=1592354738; bh=svvkyNJFRmfaM/OF0O2/vND5FS7Q0B1y53usHRnMKGU=; h=Date:To:Cc:From:Subject:References:In-Reply-To:From; b=gk55X3rGKCodh3FNyte4SK9+NNqI7fIROX3OkMVL6xllzf57zKsAQh+RETIC1iL70 z/LQBfx2Y6/KuV+mj8h12V+GqecFezpSvapZ6zsPS5ckyZCIlFOdo9K5lio645S+cy MW0nYJPJKyC4nGB9AYcVRRo5uqfD8umDtGwvLsFoaH9VxyrrOycfFA8qURyaDeLErI t9PZGexcc2efIXxN3Vb2Z+9ZqF+PopixqrcRsZSHndvo12DjO+pXfPRbrslI7a1EQx KRG6p06uT1PhVDjp44yj7p4LUAYctqUosNBImPG4PFmj8y4g8uQH2TlsfeOJyK+fCj dbOzy3LEpn1ZTuhNfJl01n3KHn3qnKemb8Z3HOPLxt2R9Mv+MIqNBz+7F86/80d/XR /sJ8IHkupECaQD1PJtIJe+HOF7iywOnMfe9aEsCMmpPsZNOIbGT+rerJwv/1e2MV5F 5vjOJ90Jf0UM5Wrtvoo6YmTMxFyf5IoMuKFPQR50+7WBcx3NgaB91K8XVabMx8N9/j hJiEV5RDztPu84E5awaXk9URpBy9xBsh3FVON9jKPvInCsx6uSRAClyyPHJaS2aesC ijlwj4Q9gmRicG9niKXyLP7DD2lG2eb1jbOEnQ1AS2givD+sASm0D8ST+P9f3d8BbJ zDsHv/+wy2dek2qCiOkr0hRI= Date: Wed, 17 Jun 2020 09:45:35 +0900 To: zimoun Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Pierre Neidhardt , guix-devel@gnu.org From: elaexuotee@wilsonb.com Subject: Re: Using --manfistest with /manifest files References: <338KGSFKQGP1E.23382XUCMS8T3@wilsonb.com> <87v9juwvn0.fsf@gnu.org> <87d062ne8a.fsf@ambrevar.xyz> <87y2opu0ue.fsf@gnu.org> <86lfko92fj.fsf@gmail.com> <871rmfwdfp.fsf@gnu.org> <2AU8F0YU6YV9A.3KVDEJ754D654@wilsonb.com> <86sgevqg8q.fsf@gmail.com> In-Reply-To: <86sgevqg8q.fsf@gmail.com> Message-Id: <268B906X3RZH5.3NHG3ABUCOVPN@wilsonb.com> User-Agent: mblaze/0.7 MIME-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="----_=_277ab8096527c65b387bdb95_=_" Received-SPF: pass client-ip=69.72.42.5; envelope-from=bounce+ec9951.08547a-guix-devel=gnu.org@mg.wilsonb.com; helo=m42-5.mailgun.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/16 20:45:47 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list 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+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=mg.wilsonb.com header.s=krs header.b=ds6NPJOU; dkim=pass header.d=wilsonb.com header.s=201703 header.b=gk55X3rG; dmarc=pass (policy=quarantine) header.from=wilsonb.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -3.81 X-TUID: JSqnqtnfKQkz This is a multipart message in MIME format. ------_=_277ab8096527c65b387bdb95_=_ MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_0daaaccd08a9e3af009aa9b9_=_" This is a multipart message in MIME format. ------_=_0daaaccd08a9e3af009aa9b9_=_ Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thank you for the direct reply, zimoun. > [The problem] is a pragmatic one. As any good Zen says: "Now is better th= an > never. Although never is often better than *right* now." Okay. If that is the case, then I very much empathize with the problem. > Going from imperative/sequential "install, pull, remove" way to the > declarative manifest.scm way, in the general case, needs to change the > format of /manifest (or add another file). Which means > transition plan, etc.. Otherwise, on the technical level, all the > material is there. That said. This makes me wonder that we may be thinking of different things= altogether. The discussion seems to have congealed around smoothing the transition to declarative profile management for users. However, the proposal I have in m= ind is *first class profiles*. I am thinking of a file that can be fed to the --manifest (or some potential future equivalent) option of various guix commands. This hypothetical file would let users operate directly on profil= es as needed. My current specific use case for this is packing the *development environme= nts* produced by `guix environment'. > I do not see why it is straightforward for some cases. guix environment --ad-hoc can be indirectly packed via guix pack unless I am missing something. Otherwise, users are at an impasse. > Because your use case -- pack an existing profile for sharing -- is not > really related to transform /manifest to a valid manifest.scm, > if I understand correctly. And I agree with you that it should be > possible to pack an existing profile (created by any mean). >=20 > Does "pack --profile-name" fit your needs? I am not quite sure this works. From the manual: > =E2=80=98--localstatedir=E2=80=99 > =E2=80=98--profile-name=3DNAME=E2=80=99 > Include the =E2=80=9Clocal state directory=E2=80=9D, =E2=80=98/var/g= uix=E2=80=99, in the resulting > pack, and notably the =E2=80=98/var/guix/profiles/per-user/root/NAME= =E2=80=99 > profile=E2=80=94by default NAME is =E2=80=98guix-profile=E2=80=99, w= hich corresponds to > =E2=80=98~root/.guix-profile=E2=80=99. >=20 > =E2=80=98/var/guix=E2=80=99 contains the store database (*note The S= tore::) as well > as garbage-collector roots (*note Invoking guix gc::). Providing > it in the pack means that the store is =E2=80=9Ccomplete=E2=80=9D an= d manageable by > Guix; not providing it pack means that the store is =E2=80=9Cdead= =E2=80=9D: items > cannot be added to it or removed from it after extraction of the > pack. I do not see how to use this with the transitory /gnu/store/-profile produced by a `guix environment' invocation. Also, my intention is simply t= o provide the profile's environment, not include the local state directory. Put more simply, I want to be able to produce a tarball/container capable o= f reproducing `guix environment --container '. I think this would be= very useful. Am I just failing to grok something fundamental? Thoughts? More generally, I think first class profiles could be both a powerful featu= re and an important future-proofing against extra maintenance burden. Profiles= are a central concept to guix usage. They form the atomic unit with which users= interact. Wanting to tarball a profile is just one use case, but future gui= x commands (guix merge, anyone?) or future --manifest options (guix archive, anyone?) seem likely to directly benefit from an existing infrastructure th= at supports store profiles being created, recreated and munged. zimoun wrote: > Dear, >=20 > On Tue, 16 Jun 2020 at 20:33, elaexuotee@wilsonb.com wrote: > >> 1. We can only approximate that actual profile content; storing > >> an approximate =E2=80=98manifest.scm=E2=80=99 along with the profil= e would IMO be > >> deceptive. > > > > Is this a technical barrier or a pragmatic one? >=20 > [...] >=20 > > If the problem is of pragmatics, then at the very least I would be inte= rested > > in hearing a delineation of the challenges. I think this could be helpf= ul for > > the discussion though. >=20 > It is a pragmatic one. As any good Zen says: "Now is better than never. > Although never is often better than *right* now." >=20 > Going from imperative/sequential "install, pull, remove" way to the > declarative manifest.scm way, in the general case, needs to change the > format of /manifest (or add another file). Which means > transition plan, etc.. Otherwise, on the technical level, all the > material is there. >=20 > So it is some work and it is not clear that it will pay off. >=20 >=20 > >> Yeah, I think our goal is just to provide a tool to migrate from the > >> =E2=80=9Cimperative=E2=80=9D way to the declarative way. Once people = have gotten > >> started with manifests, they no longer need that migration tool. > > > > Would you mind commenting on the use case that I started this thread wi= th? > > Specifically, I was trying to `guix pack' a `guix environment'. The equ= ivalent > > is straightforward for purely --ad-hoc environments but not otherwise. >=20 > I do not see why it is straightforward for some cases. >=20 >=20 > > Personally, I have already encountered several instances where this wou= ld have > > been useful. I also think it would be just plain cool to have the abili= ty to > > pack up, containerize, and share arbitrary profiles with non-guix users= =2E >=20 > Well, I have re-read your initial message and maybe miscommunication > here. :-) >=20 > Because your use case -- pack an existing profile for sharing -- is not > really related to transform /manifest to a valid manifest.scm, > if I understand correctly. And I agree with you that it should be > possible to pack an existing profile (created by any mean). >=20 > Does "pack --profile-name" fit your needs? >=20 > If not, yes packing an existing profile could be a feature to "guix > pack" -- doing transparently something similar to the Leo's suggestion > -- because it is an internal consumption of these /manifest > files. >=20 >=20 > All the best, > simon ------_=_0daaaccd08a9e3af009aa9b9_=_-- ------_=_277ab8096527c65b387bdb95_=_ Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYIADUWIQQ7FdZn/PDWvxE6cmR2pStZ7i7CgQUCXulnpxccZWxhZXh1b3Rl ZUB3aWxzb25iLmNvbQAKCRB2pStZ7i7CgflxAQCeZzGHTt1GnBh3ObZvEXtda+Gq B7uti+XuNKpigTqrGAEAhgD1pSs0zq9nDG1eWfxHZP6w+f4djv9o6kyYzkdbfQ4= =iaFO -----END PGP SIGNATURE----- ------_=_277ab8096527c65b387bdb95_=_--