From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id 4IOmHSozW2YTRwAAe85BDQ:P1 (envelope-from ) for ; Sat, 01 Jun 2024 16:41:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 4IOmHSozW2YTRwAAe85BDQ (envelope-from ) for ; Sat, 01 Jun 2024 16:41:46 +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=VLyduI2c; dmarc=none; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717252906; a=rsa-sha256; cv=none; b=imhgcFWBlR3mpKiN5CCLiR08BkA96IVcXYzLhVWyoAbRYpop73tPTrYH9j/EnEkh8AMeio Z2RCwiZxUFhgdBtKJbdzkmY1R4XjsXMyfTzrFJD2YIZOPofdGQiQAuN5QBasz9GQXfe2kK IUidMGtJE4V9J9FijmUwheiiNsXbkpIX3O+35vn6MmXaVLZdK11WpfkaTv6ZYn6ppV8k2q Y6RsTK4Cuef9skz+CmDw6hq/ZDeeDl+VOXdpJPUgvsjumPA1Bo2V36xJk+M6HJLgsEfGxR 5wSGU8YqXyp115mCRdtHku6zZwcvWmhA2GytRtFFILMzzn2hpaNMhmlkeSH0mg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=VLyduI2c; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717252906; 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=wnowmRGnu93iaU++MGT6HA4A9ej7Vxx+xo8mUEZ5BCs=; b=qz/dAcPV9wZM3epaOb+NQJOUsxAGwW/E4Ov5QkasFzuLDbLc9ZvrooWXp9e3Mg6EOUB924 woYrnzMqRZzIMloBlnqw7brSD9sOY+u5KUbFMAJ+hA5dZPmZKxcTSqdrJAN5qAsLHcis9U aNcGe19KIBnkSubDa9EU16R6kVbztS7kuxRI6GjUKoGnQPdhxDhtr3kZIqSIEO4LcbXAcN nwmjCUEbABlnHClhqaNwAS49R/QFLTWodblA+DwYG50AR9ApZS7xo/mn+uevwiGE+GuX1w mnG+tjJFXGlw3jKmTy+kf+z+W5vGfP3Dn5cFWeNCLvaaIqPihfWk5hNYXB49qQ== 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 0AF4E33B3D for ; Sat, 1 Jun 2024 16:41:45 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sDPv1-0002Qg-9P; Sat, 01 Jun 2024 10:41:15 -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 1sDPuw-0002Pb-Gf for guix-devel@gnu.org; Sat, 01 Jun 2024 10:41:10 -0400 Received: from mail-108-mta138.mxroute.com ([136.175.108.138]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sDPuu-0006oG-7T for guix-devel@gnu.org; Sat, 01 Jun 2024 10:41:09 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta138.mxroute.com (ZoneMTA) with ESMTPSA id 18fd43f3428000e2b6.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 01 Jun 2024 14:41:03 +0000 X-Zone-Loop: b746654e95f3e0df39aa77269567a22818581834d2eb 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=wnowmRGnu93iaU++MGT6HA4A9ej7Vxx+xo8mUEZ5BCs=; b=VLyduI2cEAaa3qx8Q0tBUHY71Z iKP8ItT07TBQK41WnKIzWLgjmE195Q4W17UF36W+OnBeONyYET4ZC0+MqINHlHHTSlUNi/GLq2wyY Ajkj0W/a6iq850ku6pVq56YRXlrp6zfguSLle6Mf+YzyhietopygVbkBpF/R5NbJdLmN8Fu81qVEf PbvwZFf0h5yrpFk5yudL+R79Wf4Rtbht/4Hd7zatpmXj8J/r0DRy0CNyXUQEiJrSxqrA0b33YWTma HCmvh4xsuYEzJMySI5JOQUCk8ZMMOTa8eiybYWD2tKe2gz2Wa+GMEe5lOF/MUG8WhSVwqPqs6OyyC dC4HnGBw==; 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: <87zfs4pzs8.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sat, 01 Jun 2024 15:18:15 +0200") References: <87cyp8rp2s.fsf@freakingpenguin.com> <87zfs4pzs8.fsf@gnu.org> Date: Sat, 01 Jun 2024 10:40:52 -0400 Message-ID: <87ed9g9157.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.138; envelope-from=richard@freakingpenguin.com; helo=mail-108-mta138.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 0AF4E33B3D X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -6.34 X-Spam-Score: -6.34 X-TUID: U/hWvkMZgcgz Hi Ludo! Ludovic Court=C3=A8s writes: > I understand and share the frustration regarding performance. > > To address the problem, I would suggest a different route (the problem > with the patch you propose here is that it makes things unpredicatable > and stateful: you=E2=80=99d end up using whatever commit happens to be al= ready > in a profile). > > My suggestion would be for =E2=80=98guix pull=E2=80=99 to populate the sa= me cache that > =E2=80=98guix time-machine=E2=80=99 uses. That way, if you time-travel t= o a commit you > already have in a profile, it would be instantaneous. > > I started looking into it a while back and there were some > complications, but I forgot the details. > > WDYT? Would this be an improvement for you? Thanks for the suggestion! If I understand correctly, I don't believe it would solve my problems with time-machine though for development environments. If I want to use time-machine as part of entering a development environment for some channel collection and a new guix commit is pushed, then the next time I invoke that same time-machine command there will be a large delay as Guix fetches, authenticates, computes, and builds an entirely new derivation. With your proposal, I'd only avoid that problem if I coincidentally happened to run guix pull in-between. I don't believe hard-pinning the guix channel is an appropriate solution in this case since it has several drawbacks as discussed in [1]. I don't envision this as something to be used in all cases (like reproducible research). I think it serves as a "yes, this project requires channel X, but the odds of breakage due to an update are very low and we are willing to make that tradeoff in order to enter our development tools faster". Obviously if breakage is detected in the development environment developers can choose to go back and hard-pin as required. But if we hard-pinned from the beginning we wouldn't detect that breakage as quickly. And if we didn't pin at all we'd have no speedup. Is it really any different state-wise than pinning a channel to a moving target like a branch? Instead of being unpredictable and stateful in the time domain, it's unpredictable and stateful in the user's "profile domain", for lack of a better phrase. Perhaps as a compromise we can support optionally passing some "minimum commit" (or tag). This should reduce the fragility of soft-pinning as it ensures some minimum version of the channel is present. If that's not enough, a warning could be emitted so user's know that soft-pinning is taking place and what commit is used. I'd prefer to avoid this, but it is an option. >> I think this is a side effect of time-machine serving dual purposes. >> One is providing a reproducible environment for result replication, >> the other is providing a development environment for collections of >> channels. [1]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00265.html --=20 Take it easy, Richard Sent Making my computer weirder one commit at a time.