From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id qC21BmQ5dGLRZwAAbAwnHQ (envelope-from ) for ; Thu, 05 May 2022 22:53:56 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id wOzTBmQ5dGKBGAEA9RJhRA (envelope-from ) for ; Thu, 05 May 2022 22:53:56 +0200 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 BD347F175 for ; Thu, 5 May 2022 22:53:55 +0200 (CEST) Received: from localhost ([::1]:51572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmiTy-0007VU-Ig for larch@yhetil.org; Thu, 05 May 2022 16:53:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmiTa-0007VM-OG for guix-devel@gnu.org; Thu, 05 May 2022 16:53:30 -0400 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]:40622) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nmiTY-0005cd-JD for guix-devel@gnu.org; Thu, 05 May 2022 16:53:30 -0400 Received: by mail-ed1-x541.google.com with SMTP id p18so6563570edr.7 for ; Thu, 05 May 2022 13:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=fbrKoMGnwlogkUNEHQOA2KukJYz4idW6e8j26mf8E3c=; b=adkdcOo4+bNtCwcAKa/BG24flvU6QzjaWBcGC/QHc0FeQtlxl6pVYbClN2fuo3apAM uxkQDfB2il3gDMeZ8yGUR6vOjW3Vea2+RvJ1j4J7iqvF96cQMS16FoiZtETw2pIYxxVC HD/1GJfCKyRY2h/sgzZXEZVQv9zekjQMmsB2NYmBFXDUGhyvAc2nBcCHdBVDt+DTZXrw QdOvpV5uVcakc4bUSuqkRblc9BzO9Of6TN8o/ujiaSSoVhhJMUvkMajmdavABFOghbmn XijifJOfZiRluHHTvs9ryarHfdQ51thbqBmjcjp69q2pJyHnzpasl8tuOBIOvedY5xeN srIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=fbrKoMGnwlogkUNEHQOA2KukJYz4idW6e8j26mf8E3c=; b=0LgfY+p6NJ94V228YlA6TBf9eCoBeH5ACfCepgcL0QfousyJ/6Ht/DKsaJkBUwNLit O8r1Un2ZO0krP/uuSiH1LFZ4BN4NUIxP40vMlWS1FKlhEh4cgcJcFSfRgpg8RYpPiE83 T9jpr8yZd1XP0MqkSO6F03nkiZvqV/6xA5PwHWUPcPOZT+Qa5IbUIxRHHR5qFppFmERq LXlPaXfnKKn0NHJSE79wuZRSDe/USxwvqXzrA7PL1KD4VQzSIYwkmBl+aGrixDvSB/Ve iJWt/sivnsn7pMxzUwlpCcE+XA61Bgh194Rq6V7mSRrSmXu1khvcgIdOaQm6dFxavuWa vxkw== X-Gm-Message-State: AOAM530TLAIPztz6JBAWUV91OZxwoVpDLe9O21aA9gQKTxF5/62ekKWz HMr5oPinAFEgmDNupjJUmmc= X-Google-Smtp-Source: ABdhPJxWCRnKjs/UGtmoA8VX/rYY5wyldiDRhjFwV3Zcwo6mYMOCaOJEEMonTvzGzjG8nnX9noT2kw== X-Received: by 2002:a05:6402:845:b0:427:d812:8f68 with SMTP id b5-20020a056402084500b00427d8128f68mr68779edz.73.1651784007229; Thu, 05 May 2022 13:53:27 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id be27-20020a0564021a3b00b0042617ba6395sm1283586edb.31.2022.05.05.13.53.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 13:53:26 -0700 (PDT) Message-ID: <2d0e343d6ff84281e51a8fa4e0f0b3bb54f1b7b1.camel@gmail.com> Subject: Re: Multiple profiles with Guix Home From: Liliana Marie Prikler To: Maxime Devos , Andrew Tropin , guix-devel@gnu.org Date: Thu, 05 May 2022 22:53:25 +0200 In-Reply-To: <0fa7c8f3068e5c5f8192b307fcb3446b0724dbf9.camel@telenet.be> References: <8735hqvh4a.fsf@trop.in> <8a42a0c84d35231b360a421fe0b846c8e1aa3d2c.camel@gmail.com> <8b66e609b7c9d5183017ccf7fef47c818fcea231.camel@gmail.com> <25e0ca9be4053c94d12461ec42f1985cd6730a8f.camel@gmail.com> <07907034239128b36890690703fe6cb6b4ce958e.camel@telenet.be> <53eabd93a0e41723ad3e0238314e630e713f8cfe.camel@gmail.com> <4bb446ca24b57f648d1dd4f0083010d9ee35c40f.camel@telenet.be> <28dcab6db488b73a95bfe349a3e97a3f4f5ec345.camel@telenet.be> <330265fe1014a4015dc64ec645f6c1171771b1df.camel@gmail.com> <03221fd1743fb50325dff2604f7b4fc3ae450c1b.camel@telenet.be> <0fa7c8f3068e5c5f8192b307fcb3446b0724dbf9.camel@telenet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::541; envelope-from=liliana.prikler@gmail.com; helo=mail-ed1-x541.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 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-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1651784035; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=fbrKoMGnwlogkUNEHQOA2KukJYz4idW6e8j26mf8E3c=; b=iahYU+4AWhP3i3liNcvAQQHMVz/TLb6U3W1vsE2KqqhPXncwI1MDQtoL99On9ZL6Y954tE p2iqd7B9hhLpMPuELTEGvSuEJxnCwksbTY/+gPX/EtpJB8gOILmtxC3EdcgdJT/rGQsux1 EyrWVwRCeGlvr2Uifj7UgkfYM0gCxEN/9unklc2gTStiV1GjAAQptAZl8j2MYhovsmEIwT 6PeQkFfiDuER6FY89iPQXe9MnvjV9p/+9qsTMvilWzIAWit4mt38K6oY7GETZAjtDBfch4 qoWfDjekaNw/N05M9EY4z8Fzo1RSdxCMIjCa844YPwdjZi/GOnqT3ZxvCKJ4Ww== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651784035; a=rsa-sha256; cv=none; b=i9fGH6gZEH7XLYGyVpDF1E+6sZr7/TVvxgflTV3hQMvAJgNFRaEV+KWmFHCXmZAYjIrhsp miJVnDIwy4IgtuOLsmbaXhe8BYwZEH0Wp8UFRjYyAGKj/rWOplL+8g6yy9hYHNiki0xYBL i8FXFuvHGWBr3MCty9/xLlkHFZdUlc1B+TBtq4eM4qPNb4U+LnsMmn09/ZOGrfGqMYCGJQ yMT0qB/mAuI8VgSsQZ/MqV+9ZLMyepGSysrxXPD8WUE3U2LY3GqZFYn/9OytpF6dHguLqu zBEU48nkj2yL7tCXz3m0oduckfcKR2VNuqXNYNYq6ZZczJrNVZ3A714g1OHHVQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=adkdcOo4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -5.49 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=adkdcOo4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: BD347F175 X-Spam-Score: -5.49 X-Migadu-Scanner: scn0.migadu.com X-TUID: ZPCjLUkGyXQt Am Donnerstag, dem 05.05.2022 um 22:13 +0200 schrieb Maxime Devos: > Liliana Marie Prikler schreef op do 05-05-2022 om 21:08 [+0200]: > > And you're not taking into account my time cost of debating you > > when I already have manifests split across many files that I want > > to manage as separate profiles using Guix Home, kthxbye. > > Debating things is a one-time cost, whereas potential time > savings/time increases will be a gain for all future users / a loss > for all future users.  Also, didn't you ask for comments on your > proposal, implicitely by sending to guix-devel@ and explicitly by > > > What do y'all think? > > ? I did, but I assumed that people are already aware of multiple profile workflows and the pains associated with them. Having to debate the semantics of a 2.5 year old blog posts should not be necessary in any of these steps. This is an initiative for enthusiastic users who want to split their profiles, not a trick to convince them of doing things outside their comfort zone. The aforementioned sanitization overhead when using the old configuration should be comparatively small, otherwise we need to debate field sanitizers. > > But to entertain the idea, suppose Alice wants to make her profiles > > smaller so that they build faster.  Which sounds more reasonable? > > Bundling groups of packages that fit together into their own > > manifests, then instantiating one profile for each, or rolling a > > six-sided die and putting the package into whichever bin is number > > four?  If you're a machine, you probably think the latter.  > > Seems like a false dichotomy, why not: Alice teaches Guix to do the > equivalent of rolling a six-sided dice, so she doesn't have to figure > out a bundling and she doesn't have to manually roll dices.  Now, > teaching this is a bit of a time investment, but she shares it with > all other Guix users, so everyone benefits of automatically better > performance. You are aware that by rolling a six-sided die I did include "clever" applications of rand, are you? Even so, your profile splitting won't go anywhere if you don't have a data representation of what a split profile actually looks like. Which sounds a lot like "I want the benefits of your system, but I don't want the user to profit from them by making an explicit choice on their own". If that's your take, I have to hard disagree. > > What could be more fair than a six-sided die?  Why, a seven-sided > > die of course! > > I assume N-sided die = N-separate profiles here?  If so, not sure > what the 'fair' is about?  Taken to the extreme, why not N separate > profiles, where N is the number of packages? Fair as in balanced, meaning all the bins are of equal size. I'm not stopping you from allocating N bins or even 2N bins, but I would rather you take the hint and not debate pointless side topics. > > We disagree about the question whether users should be granted a > > method of declaring multiple profiles to use for their own purposes > > in whichever way they see fit through `guix home'. > > I don't?  Well, initially I didn't see a reason for multiple > profiles, so I asked for reasons, and eventually, a few reasons that > weren't addressed yet by other things were mentioned (e.g.: tidyness > of separate profiles, some kind of minimalism where one only has > packages in $PATH and other search paths that are currently > neccessary by manually activating a profile that has a selection of > packages)? Note that the context has always been placing multiple profiles in well-defined locations. It was assumed from the very first post that you have a use for those, or at the very least that you don't mind others having a use for them. > > > there is no need to do so whereas I not only claim there is, but > > also > > that any existing way of achieving similar results fails to meet my > > requirements, which are: > > > > 1. multiple profiles can be configured at once > > 2. profile locations should be specified by the user > > 3. profile generations are not littered, instead, the user has a > > way of linking to /var/guix/profiles/per-user > > 4. both package lists and manifests are supported > > 5. existing configurations can be expressed in terms of the new > > system > > 6. individual profiles can be "disabled", i.e. not sourced during > > activation, but still built > > 7. individual profiles can lack a manifest, in which case nothing > > is built, but they are still sourced on login > > (2) is already achieved by "-p". Only works for updating, not sourcing, see enabled? > (4) is already achieved by "-m/ no -m" See (2). > (3) not sure why the user would care about /var/guix/profiles/per- > user There are very important aesthetic reasons to place generations there rather than literally in the user's $HOME. > (7) is already achieved by "guix install" / "guix package -m". The > ‘source on login’ isn't though -- half-achieved? It's not. You can't currently declare a noop profile in any Guix command. A noop profile is distinct from an empty profile. > Remains: (1), (5), (6), (7) not yet completely achieved. > This kind of list was what I was asking for. > > > [...] along with any underspecified search path > > For the latter we still need a solution that works regardless of > > guix home anyway, so it is not a point of discussion here. > > The extra Guix Home feature magnifies the problem of search paths, so > it seems a point of discussion here to me.  Especially since solving > it for Guix Home profiles seems a lot less complicated than the > general case to me: just compute the set of search paths (combined > over all packages in all the profiles) and use these search paths for > all the profiles. See Andrew's objection in the light of non-managed profiles. And I have to agree with Andrew, I don't think computing search paths over all profiles is the best solution here. Rather, having search paths be a first-class citizen of manifests, i.e. allowing them to be specified in addition to packages, sounds like a solution that works in all contexts except perhaps the command line without eval. Cheers