From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id 4FODOQFJXWb2zwAAA41jLg (envelope-from ) for ; Mon, 03 Jun 2024 06:39:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id yJ8MNgFJXWY7uAAA62LTzQ (envelope-from ) for ; Mon, 03 Jun 2024 06:39:29 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=CqDPVafr; 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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717389569; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=dvv4NG6f96HQgc4wfxpl/MxhTC9qXsnabzEJYolypg8=; b=gQsZbV7MXbJPv4FYF4cxEMBhF2zRXV3WYFM9P38tkXDYiqygTW7qbHxfBrWTfex7ArQ9V2 VN/m5sNwYYrpxu1ZEaYTYVSNDdJBsw/M0f9s5yrr6cLFVQomTXf3oh2OKuVlLtiOh/FFsV WSQ6iQ59pfsZEN1Ud9qGy4GGdDt4Dp2xcWKcZBZ3xHdsFiRVM4bczR8zwXfOHwArEstYXG maPTIR9ek4HRibCITvTvrTvpAzL/dk6+reYCd0tg5MXb/Wtwig712rZRy0+wfZ7FWcLJae gXPDEV8gxjNQLeXgrPesrNNNIInzuAVDd5TUqpxfK39Jdt0pMOwUBGhtwVE2qg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=CqDPVafr; 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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717389569; a=rsa-sha256; cv=none; b=aBA0ABuvHx/MYWjB2nzFpueWWZEe/4buOSR0htW3BTNfC0UFSTA6Bj5vvlLTYnw7vCK67y o+UNrI0Qc1YC+OruKZzv1NengR/mAqDqb5GUPjXjO10xyMYAuYvPbMR1NMoHg9tuAzz7b7 qN+/ELKgG2H2HO1++BoKoe8x9tWBDkKBBW0cyKsK0DoPN7AyDRua9WesuErneHnTVER0OT cCNdT7sRQvKrx1MOZU+RZDKOB1aSqL1CRvgHPoLUBYKQdQ5BEU9JQqcKcWobl8GPd36MYB 4jxweDOBW8ucwP9tg1/50c+M4LQQr0KdU6ZzhOFpNUu0kPsveL5o8wuSOMw4UQ== 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 ACB5F618B7 for ; Mon, 3 Jun 2024 06:39:29 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sDxt8-0001xS-6H; Sun, 02 Jun 2024 22:57:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sDxt4-0000sk-OC for guix-devel@gnu.org; Sun, 02 Jun 2024 22:57:30 -0400 Received: from mail-108-mta129.mxroute.com ([136.175.108.129]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sDswF-00070Y-64 for guix-devel@gnu.org; Sun, 02 Jun 2024 17:40:30 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta129.mxroute.com (ZoneMTA) with ESMTPSA id 18fdae5813d000e2b6.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sun, 02 Jun 2024 21:40:25 +0000 X-Zone-Loop: 7de165a39bad2c99bac882d7869b6709f98a94147764 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freakingpenguin.com; s=x; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dvv4NG6f96HQgc4wfxpl/MxhTC9qXsnabzEJYolypg8=; b=CqDPVafrADDdy7gs0ctf+tdvj5 /CJ3cakL2eb1D5dURCW89W3Rzc7oHba8XXMQyTFVppwsUIzPIllCU9YlVzP8RKtFxp895MfO9ish3 Xu0BXJO2l9Tbbe/Lb0jZHu4SvuMYIBXPMzE9sezNo/U24bPgM4VRCmHKfAB0szbNW/KeKZserRnVs TtoB7AXgEUn1cmuMh0gKlj9+TgbEpzFyJJoplirb45+y3/11xQffZ1VFdHGqP3GKlmTnM+uwArCV5 SkHqriQhIQ1GmfeBnFLO07XYji3o/wCSn7OjHxbiTbO5JvR2CMCR5kRUwljo3CqB+GlAteJY1rB9z 3eqkwk9w==; From: Richard Sent To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, jbranso@dismail.de Subject: Re: Improving the speed of guix time-machine for development environments In-Reply-To: <87jzj7jccn.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sun, 02 Jun 2024 22:53:12 +0200") References: <87cyp8rp2s.fsf@freakingpenguin.com> <87zfs4pzs8.fsf@gnu.org> <87ed9g9157.fsf@freakingpenguin.com> <87jzj7jccn.fsf@gnu.org> Date: Sun, 02 Jun 2024 17:40:19 -0400 Message-ID: <874jabdnwc.fsf@freakingpenguin.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Authenticated-Id: richard@freakingpenguin.com Received-SPF: pass client-ip=136.175.108.129; envelope-from=richard@freakingpenguin.com; helo=mail-108-mta129.mxroute.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.34 X-Spam-Score: -6.34 X-Migadu-Queue-Id: ACB5F618B7 X-Migadu-Scanner: mx13.migadu.com X-TUID: hAs1bx+vQZdm Hi Ludo, Ludovic Court=C3=A8s writes: > I=E2=80=99m not sure I understand the use case. Two different but =E2=80= =9Ccommon=E2=80=9D (?) > use cases come to mind. > > First one is when you want to share the exact same environment within a > team of developers, say. In that case, you have a =E2=80=98channels.scm= =E2=80=99 that > pins commits. The first =E2=80=98guix time-machine=E2=80=99 is expensive= but subsequent > invocations are instantaneous (cached). Occasionally, the team updates > =E2=80=98channels.scm=E2=80=99 to point to a more recent commit of Guix a= nd other > channels. > > Second one is CI-style: you want to build a package against the latest > commit of each relevant channel, all the time. In that case, you pay > the price on every =E2=80=98guix time-machine=E2=80=99 invocation. > > You seem to be looking for something kinda =E2=80=9Cin between=E2=80=9D, = is that > right? Yes, that "in-between" use case is what I'm going for. Hard-pinning solves, for example, the "random 5 minute time-machine when invoking Geiser" problem (minus the first use), but introduces others that aren't universally desirable in a short-lived development environment. In other words, it's overkill sometimes. :) In a development environment, I want to achieve two things that are diametrically opposed: 1. Responsiveness/Speed of entry 1. Should be obvious why this is good ;) 2. Continual updates of channels unless explicitly pinned 1. Detect breakages faster without needing a dedicated Cuirass CI server. 2. Less maintainence burden to regularly update pinned commits, particularly as a channel dependency tree grows. I feel that soft-pinning strikes a balance between those two goals that is useful when dependencies on a frequently updated channel are unlikely to break between commits. Elaborating on 2.2, consider a dependency chain that looks like --8<---------------cut here---------------start------------->8--- _______ / \ / v=20 Guix-->A-->B --8<---------------cut here---------------end--------------->8--- If B hard-pins Guix to "foo" and A is updated to Guix "bar", B needs to update their hard-pinned Guix commit in channels.scm to >=3D "bar" to have a functional development environment again. Alternatively, B could hard-pin A, but if A is a channel the developers of B control they probably want to always use the latest version. Now you're in a catch-22 situation of "Do we hard-pin Guix in B and manually update it every time A's requirements change, or do we not pin Guix at all and deal with regular 5 minute pauses during development?" As channels become more popular and dependency trees grow, this'll become even more annoying. If B is only importing a couple Guix modules that are unlikely to incompatibly change, it's basically wasted effort. This is outside the scope of this topic, but I think it could be interesting if the dependency channels in .guix-channel could specify minimum commits as well. --=20 Take it easy, Richard Sent Making my computer weirder one commit at a time.