From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 2MyVH5PpBGYVngAAqHPOHw:P1 (envelope-from ) for ; Thu, 28 Mar 2024 04:52:51 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 2MyVH5PpBGYVngAAqHPOHw (envelope-from ) for ; Thu, 28 Mar 2024 04:52:51 +0100 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="fOBS/VjK"; 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=1711597971; 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:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=kbSwfHeA57tlQqnc+HzLWDhXg30v9a35e7FaL05GC6Q=; b=WsPmgo1zDWpR9dMuWaMq1b1wglVvN0KeoMmIlmeI22Xivp6dQlQYgsbJwCd1+uVLoTwgBL BCCEZWnCe29tXSdIztmGFP+wiBIvodZWIZRL+cOC7qoM6RwOtmelRGNSNvXyjJ6MHBUdEr VaqrE7jT4UKNIXTNHgal9MQNWk5lU3n+VR8fjBlTH5MhVYmYMZOvOy8/DN9UTZ4m2eutT/ P/vIVkF7P4RR+qrBBbXcjaKmovnJND42hJXFyXnjnBYcXMoe7XNxbxyc5XHYLDPyCrtlWG KhhEb9igYUDwN8HlJfijrZYH7LY9NJgfojz77q3VKsVoSNq2h82gMUmOhK/amQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b="fOBS/VjK"; 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=1711597971; a=rsa-sha256; cv=none; b=rpo5klordB1JfKZTM5WcaZjYc3A519BXOAl6ijSdaZQ0tPBLgbp+cpZw6wTMfU8Ly5KBHc +MFs/Md7YOrG2YqSz9lN1IeJVL8wRL8P+wN42UPmXdRoaXo9R0k3JUiEqLkv9z6r+Hc29U hYxN8VQQYx6koHgGlg22ReXWt36Dn0tm0J2KFdMlpxyI1FJEc/JCXWw4creC60XuAkdLvb o+qzLns+BrGT6MfpsD7cMc3nmVw4DXEzP1OZsO/atDMNpouPFXoixa5XuvkTSLQEHLBXTE dasS1BJtlEf8sQwMmtsGrpCOhW5Kk8hO//HbbEimzcuxRXVxw2XJLjCPyOQaug== 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 40A2459B28 for ; Thu, 28 Mar 2024 04:52:51 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpgoO-0000LZ-RB; Wed, 27 Mar 2024 23:52:20 -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 1rpgoL-0000LB-Fo for guix-devel@gnu.org; Wed, 27 Mar 2024 23:52:17 -0400 Received: from mail-108-mta196.mxroute.com ([136.175.108.196]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rpgoJ-00078M-GM for guix-devel@gnu.org; Wed, 27 Mar 2024 23:52:17 -0400 Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta196.mxroute.com (ZoneMTA) with ESMTPSA id 18e832fc9f00003bea.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 28 Mar 2024 03:52:10 +0000 X-Zone-Loop: d66c24e5bc35beda746ffd6c6f91626f7614f178b81d X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freakingpenguin.com; s=x; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=kbSwfHeA57tlQqnc+HzLWDhXg30v9a35e7FaL05GC6Q=; b=fOBS/VjKeWLlXLn6yZhHORkRPl zyRhA2UvIpQ4cqGb/y/Eg+FtZDRXaRM+zuLeIsj8Fvh4oyNgWGD9wSGB1FUqWW886dyKzp6VQG6rB yBRZ7pPFEFRZQJid7RxTeVORcZ0ELhWgbJu/lxv5trH+TB14PWBF+vcPfExv6KrGXn7adYrEO8SOw 2vhyqLOpDcEID0uHM49LXklJUAIl2XFpYUcO1LmoCtZLXpvj+/pcwEMFFgZfMMvZgUJqcctZRDJnH yyGLompfr9eejYlfb+UoSabS3TZfwo0lm7B1CS2VvYpC5s2S5XbFmTGGjlOnJfdRxkqA5ZNfxamtS +xsjrj5Q==; From: Richard Sent To: guix-devel@gnu.org Subject: Improving the speed of guix time-machine for development environments Date: Wed, 27 Mar 2024 23:52:03 -0400 Message-ID: <87le63qaho.fsf@freakingpenguin.com> MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: richard@freakingpenguin.com Received-SPF: pass client-ip=136.175.108.196; envelope-from=richard@freakingpenguin.com; helo=mail-108-mta196.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 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-Queue-Id: 40A2459B28 X-Spam-Score: -4.85 X-Migadu-Spam-Score: -4.85 X-Migadu-Scanner: mx11.migadu.com X-TUID: a9lJ+LEeN8pJ Hi Guix, To my knowledge what I'm asking for can't currently be done, but if it can feel free to disregard. I think channels listed in channels.scm files should optionally support using whatever channel version is already in the user's profile, if present. This would significantly speed up entering development environments composed of Guix channels. Consider the following situation: 1. Repository A contains some code, an unmerged Guix package, and a .guix-channel file. 2. Repository B declares an unmerged Guix package that depends on A's package 3. Repository B doesn't want to duplicate the package definition in A, so it adds a channel dependency in B's .guix-channel 4. Repository B wants to make it easy to enter a development environment that includes repository A's channel, so it tracks a channels.scm file with the following content: --8<---------------cut here---------------start------------->8--- (append (list (channel (name 'B) (url (string-append "file://" (getcwd))))) %default-channels) --8<---------------cut here---------------end--------------->8--- Now in order to build B, I need to enter a Guix development environment that includes A's channel. The only option I know for that is time-machine, e.g. "guix time-machine -C channels.scm -- build -f guix.scm". Unfortunately, *I may be delayed every time I enter the development environment by several minutes while Guix computes a new derivation due to an update in %default-channels*. time-machine will update ALL channels in channels.scm to the master branch (by default) every time I try to enter a development environment (e.g. "guix time-machine -C channels.scm -- shell -CDf guix.scm"). I don't think pinning Guix to a specific commit in channels.scm is the right solution. 1. That increases the maintenance burden (If A updates to use newer Guix code, now all dependents of A need to be manually updated to use newer Guix commits). 2. It makes it easy to mask breakages for an extended period. 3. It implies that B doesn't work on newer versions. 4. Any developer working on the repo will pull an unneeded copy of the channel. 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. My proposed solution is to add a (prefer-local?) field to (channel ...). When set, time-machine would first see if there is a channel with the same name in the user's profile. If so, it will include that channel in the time-machine environment instead of fetching it. If not, it behaves as normal and fetches the channel from url. As a workaround, it *may* be possible to achieve this via a command like ~guix time-machine -C channels.scm --commit $(guix describe |