From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id uBjLBJ/1X2FumgAAgWs5BA (envelope-from ) for ; Fri, 08 Oct 2021 09:39:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 8FV9AJ/1X2EXIAAAbx9fmQ (envelope-from ) for ; Fri, 08 Oct 2021 07:39:11 +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 51FF01B9B0 for ; Fri, 8 Oct 2021 09:39:10 +0200 (CEST) Received: from localhost ([::1]:56948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYkTF-0002Do-GG for larch@yhetil.org; Fri, 08 Oct 2021 03:39:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYkT8-0002Bk-L1 for guix-patches@gnu.org; Fri, 08 Oct 2021 03:39:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:37407) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYkT8-0000PH-DX for guix-patches@gnu.org; Fri, 08 Oct 2021 03:39:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mYkT8-000776-BH for guix-patches@gnu.org; Fri, 08 Oct 2021 03:39:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#50960] [PATCH 10/10] shell: Maintain a profile cache. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 08 Oct 2021 07:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50960 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxime Devos Cc: 50960@debbugs.gnu.org Received: via spool by 50960-submit@debbugs.gnu.org id=B50960.163367868727275 (code B ref 50960); Fri, 08 Oct 2021 07:39:02 +0000 Received: (at 50960) by debbugs.gnu.org; 8 Oct 2021 07:38:07 +0000 Received: from localhost ([127.0.0.1]:48953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYkSE-00075r-HM for submit@debbugs.gnu.org; Fri, 08 Oct 2021 03:38:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYkSC-00075N-Fq for 50960@debbugs.gnu.org; Fri, 08 Oct 2021 03:38:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59930) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYkS6-0007yb-Is; Fri, 08 Oct 2021 03:37:58 -0400 Received: from [193.50.110.91] (port=39742 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYkS6-0001sR-4S; Fri, 08 Oct 2021 03:37:58 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20211002102240.27815-1-ludo@gnu.org> <20211002102240.27815-10-ludo@gnu.org> <91012c32e4f8b04beae71378d44787a81055391a.camel@telenet.be> <87ilyfy0q4.fsf@gnu.org> <87lf39ryle.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 =?UTF-8?Q?Vend=C3=A9miaire?= an 230 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Fri, 08 Oct 2021 09:37:55 +0200 In-Reply-To: (Maxime Devos's message of "Mon, 04 Oct 2021 17:58:41 +0200") Message-ID: <8735pc6k6k.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1633678750; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=OZ7OfOIrXAZICNl16hN//BCKXwXApYGsgqS7VcqA7GA=; b=QB5fJlwz9r0nUtL4u4L0SZeDXVkQlxKE6OTuGmgIVmqYWd52KfJeo4GOziqRn5CSt+h58K 12j6b//3FI6a0HoKwDwC4a8R6JCwUJihmJcecaQK1NZ3is//UIGT1EhNxRGfVyCFiazg4y EnYnsVte6FqFGFJGZsczz7PQdgWGrQuvX7oxcfc540g7wigEDiVlEWM/dnhvjlq9QSXwua PcR7td97CvX2cOffNQU5uubjFqFcQqZMzJ8/TpVIZ678BlUxUzI64VDU3YKcpmA/H5ELMN tf7m0sUL7CqSgsaFSbn6mRdpmjPXeXqvMSa0R3UTAql5k4H3yDh/rWhtQ28+zA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633678750; a=rsa-sha256; cv=none; b=l7EejDCJxge5D0oP2kIqB6G2Fvi9X+qSbA344DjZl11Jm9qU1p2RFt4Ixl07p0XoQZiF0z aE0CADMqJyk/9RWtyBnowtfhP/if5swE7VmyyKOg0tSY9lzGSjgYrlZU7ZA5POw7drUy+5 n/PP5V+b5lt5jxPb/vM31A4L0LmDQl3zVyBYUJVScyZjU2eI8AGglxQGUY9CuxGLAmOUlX xfX2OuSFveFgp3zLBShm5mSTdIi/ouo4UbIQqtCpvscISRDLsxbCAUkAup5kALH7fj83Yy 6C0hBBbYOraO48klN2fk8/kzi8v5qhLXwbJNLRokTZDzTHPPk5H6k3AlAzB/iA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.41 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 51FF01B9B0 X-Spam-Score: -1.41 X-Migadu-Scanner: scn0.migadu.com X-TUID: m3BXDtKm4Jse Hi Maxime, Maxime Devos skribis: > Ludovic Court=C3=A8s schreef op ma 04-10-2021 om 10:19 [+0200]: >> > A documented flag to always consider the cache stale seems good, thoug= h I think >> > at least the dependencies made with the common macros and procedures '= include', >> > 'load', 'include-from-path', 'load-from-path', 'use-modules' and non-r= ecursive >> > 'local-file' could be tracked, though this could be left as a TODO for= later >> > I suppose. >>=20 >> Tracking those uses reliably is impossible: there could be same-named >> bindings that do other things, there could be custom macros, there could >> be =E2=80=9Cdynamic arguments=E2=80=9D (whose value is not known statica= lly), etc. You >> have to expand + evaluate the code to get better results, and even then, >> there might be different paths in the code so you can=E2=80=99t be sure = you got >> it right. > > I think there's a miscommunication here. From what I'm reading, what you= have > in mind is that, to determine the dependency information, "guix shell" wo= uld > open "guix.scm", read it with the procedure 'read' and sniff for 'load', > 'include-from-path', 'load-from-path', 'use-modules' and 'local-file' form > -- something like 'module-file-dependencies' and 'extract-dependencies', = but > more general. Yes, that=E2=80=99s roughly what I thought you had in mind, sorry! > However, my idea is to replace these macros, such that, when "guix shell" > loads "guix.scm" or "manifest.scm", these macros inform "guix shell" > that "guix.scm" or "manifest.scm" depend on certain files referred to > by 'load', 'include-from-path', etc. forms, using a mechanism like the > 'notice-dependency' defined in . > > Then, when "guix shell" puts the resulting profile in the cache, > it includes the generated list of files. And when "guix shell" finds > an entry in the cache, it will check if the files in this list (and guix.= scm > or manifest.scm of course) have been modified. If some are (or the forci= ng > flag is set), guix.scm needs to be loaded and a new profile needs to be > generated. If they are all unchanged, guix.scm will _not_ be read: the c= ached > profile can be reused. > > It's not 100% reliable (e.g. the list of packages in the manifest could > depend on the phase of the moon if (current-time) is used) (is that what > you mean by =E2=80=98different paths=E2=80=99 and =E2=80=98dynamic argume= nts=E2=80=99?), but it should > cover the vast majority of cases. > > I don't know a non-artifical situation where =E2=80=98custom macros=E2=80= =99 are a problem > -- do you know an example in the wild where this dependency tracking sche= me > would fail to work? I think we have to look at the cost and at the benefits. The cost: either we spread =E2=80=98notice-dependency=E2=80=99 calls all over the pla= ce, or we interpose on =E2=80=98open-file=E2=80=99 altogether, assuming that even wor= ks. The benefit: we=E2=80=99d have an 80% solution. There would still be edge case= s not handled correctly; a realistic example is a =E2=80=98guix.scm=E2=80=99 whos= e execution differs based on the presence of a file or environment variable. People would have to know about this pitfall and pass the right flag. [...] >> In such situations, I err on the side of not even trying. The added >> complexity for a flaky result doesn=E2=80=99t pay off to me. I prefer t= o be >> upfront, document limitations, and let users handle them as they see >> fit. > > About complexity: there's some extra code, sure, but it doesn't seem comp= lex > to me. To track dependencies in , > I only needed to add 'notice-dependency' and some other code to (guix bui= ld compile), > and some code to build-aux/compile-all.scm to save/load the dependency in= formation > to/from the builddir and to also check the mtime of dependencies. > > Does it still seem flaky to you, after my explanation on how the dependen= cy > information would be determined? > > Being upfront, documenting limitations, and having a =E2=80=98force rebui= ld flag=E2=80=99 > (is that what you mean by =E2=80=98letting users handle them as they see = fit=E2=80=99?) > (possibly also documenting 'notice-dependency') is not incompatible with > the automatic dependency tracking. > > More abstractly, this seems more like a =E2=80=98Perfect is the enemy of = the good=E2=80=99 situation. > While I would prefer 'perfect' above 'good', and the automatic dependency= tracking > certainly isn't 'perfect', it does seem 'good' to me, and perfection appe= ars to > be impossible and there's the =E2=80=98force rebuild flag=E2=80=99 as an = escape hatch, so I believe > 'good-but-not-perfect' to be acceptable here, as long as it is documented= in the manual > that there are some limitation on what dependencies are automatically tra= cked. Yeah, I can relate to that sentiment, even if I=E2=80=99m all too often on = the =E2=80=9Cperfectionist=E2=80=9D side of things. ;-) I guess I could live with an 80% dependency tracking solution. However, my criteria for it would be that (1) it should be orthogonal (e.g., not requiring explicit calls to =E2=80=98notice-dependency=E2=80=99 in many pla= ces), and (2) it should be self-contained and reasonably small. Perhaps having =E2=80=98load*=E2=80=99 or similar instrument =E2=80=98open-file=E2=80=99 o= r similar could help achieve that? I would rather not block =E2=80=98guix shell=E2=80=99 on that though. WDYT? Thanks for taking the time to clarify what you had in mind! Ludo=E2=80=99.