From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id iEHGOJ56VGExoAAAgWs5BA (envelope-from ) for ; Wed, 29 Sep 2021 16:39:26 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id aFNRNJ56VGGDewAAB5/wlQ (envelope-from ) for ; Wed, 29 Sep 2021 14:39:26 +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 127D82C325 for ; Wed, 29 Sep 2021 16:39:26 +0200 (CEST) Received: from localhost ([::1]:37550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVak1-0003rS-76 for larch@yhetil.org; Wed, 29 Sep 2021 10:39:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35002) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVahi-0001PF-GS for guix-patches@gnu.org; Wed, 29 Sep 2021 10:37:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:38228) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mVahi-0001v1-7G for guix-patches@gnu.org; Wed, 29 Sep 2021 10:37:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mVahh-0004NV-Vl for guix-patches@gnu.org; Wed, 29 Sep 2021 10:37:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#50620] [PATCH 1/2] guix: packages: Document 'computed-origin-method'. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 29 Sep 2021 14:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50620 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: zimoun Cc: Mark H Weaver , 50620@debbugs.gnu.org Received: via spool by 50620-submit@debbugs.gnu.org id=B50620.163292621816819 (code B ref 50620); Wed, 29 Sep 2021 14:37:01 +0000 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 14:36:58 +0000 Received: from localhost ([127.0.0.1]:49774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVahd-0004ND-LJ for submit@debbugs.gnu.org; Wed, 29 Sep 2021 10:36:58 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:37577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVahS-0004Mb-AP for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 10:36:47 -0400 Received: by mail-wm1-f67.google.com with SMTP id r83-20020a1c4456000000b0030cfc00ca5fso5491234wma.2 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 07:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=hp3EsMoBt1CMz4OdqaDHj9Krv1cJBZJqUmegGHoMyQ0=; b=D+VAgiQA2VN7CY+BxIKYq18aWIjOSFg/4brWZCe1OSnc5UCVNUu+EcOoEQAD/feqR+ AyTdHbIqImDgGEdqLinz+xfQmB6UDr7kgZuTnC16K0ZeeE+nQgMDgitYwhCMWxsVqS7M qSdlqXef9zogwaZxGqaF16HXGPXRZ8Xow6dEKfgPqACFoR5lxtOsftmcidKH7POwKPbZ W/fk2WxKep8cvVqp4/WmnPd739c0Hokt6yzM8jb5CRO6GH9x0sLIJAZHzXRsNdKDXtNf +J9PmWU0/0KaXU1NS4Gm+Ekb/uCnKRFfr+oXBsyhZmAFCcPsIfOSHNKTzvW1YjCld5Es Bz9w== 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:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=hp3EsMoBt1CMz4OdqaDHj9Krv1cJBZJqUmegGHoMyQ0=; b=Pl5y0s2mLDAlE+n1XaaxHXY7sXbLMVLHkF8cK1MVbhMrsYRW6eqB9mT9PKa2OU4UUA auVfE9K1cN0xUgRZtvBonfunjsrk5dtIGEGya6M1tO4q1zfhURCS7eXC4CItWnZNDHTC pFhNp7d0oRo/1IrwsbOHX+JVnvm3eJRvcaD+82ZIdrQaKfePCpYpXt4EqA5EkEQfNc0B qfAkqGZjxrg0Y91FXJZkgUDw8+1oyGtOzoh2HrEO+qQKrWR0DxrfvMYabsehvyIgl1jk RXNo4q7JJquGp6HBs7LJBgit/SwN5Ck63xCnKQv3JlWREyFQ4tmdtoUtojGyXsLirycl fEbg== X-Gm-Message-State: AOAM530INWsGMIo2sBrNHlKcLXgiEX++7G24uKSG0XfpeShPZFl/Geam aN33kHdB2bXT1SVE+2tuDFg= X-Google-Smtp-Source: ABdhPJwJG3dJJjNI6SuE3QdsQov9RuSAE7exeewQK8oAaFuCIzpECpsmkJJAQJwsJe4+4lxgOlVu1Q== X-Received: by 2002:a7b:c391:: with SMTP id s17mr10905092wmj.139.1632926200226; Wed, 29 Sep 2021 07:36:40 -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 t11sm68012wrz.65.2021.09.29.07.36.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 07:36:39 -0700 (PDT) Message-ID: <756ae01852047a7adc2522c025c8cd7283dc7e55.camel@gmail.com> From: Liliana Marie Prikler Date: Wed, 29 Sep 2021 16:36:38 +0200 In-Reply-To: References: <20210916114734.2686426-1-zimon.toutoune@gmail.com> <9b6ee27ff10e1042a5d61d0f93d957cf760e9ecb.camel@gmail.com> <87v930ay5y.fsf@netris.org> <87pmstghx0.fsf@netris.org> <1803ff0456849f456c6994d47cbe50d1a8ff6a09.camel@gmail.com> <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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=1632926366; 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:dkim-signature; bh=hp3EsMoBt1CMz4OdqaDHj9Krv1cJBZJqUmegGHoMyQ0=; b=k9zUaGT5mkbFbW4dZdRFA4khk/1poDegQBxm1kctxjiXF00MIROAaRi6bh3dJZzxaJbYKR vmfj5Ern40OdxrMsrsg/nh1D7bgPcxmMtR3eX61DO44jbAYiuxBCSfR1w8IJD5n4okkm9+ xvmabeyWgVT7DFQkNwzqDobtlQ/aUB1E+guIbJxvsFC1zNIjsRWfZ3+45bDjA/7ZRXdkdh XEX99aCZbRhGWcbe9dCcdNJQmcu0IkNU7+++/wQ2MC04oTxMZEOojqCcqDNtBCh4oOf9Su hYrAVlcBKZ0vsH1IAvxSN1jCXjVtohCw5q1EZMF9KgZ6llrLVhtdaGhWYls9Nw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632926366; a=rsa-sha256; cv=none; b=aULCyocDkaqfHj4wrJYe3Q1cqOWhbFjUnHSLM+K1+LyrILEKLvD2X4LwRjQdmlJD41y1fR 0EzSuGxsZTcCorjIW2C1P7GF2Nrzk00HKxkYSaSWlLMX3s6XWLp+/NvQ7UVKXiwpaLta9m DZVlZn3zdgQHenx7Ifp6yD7TYJB1gADyMKuLDqjOD4CtdrM1ItxndRH995DWy7gHNEUWqB Cx3TkTR7fTJ02XhT+u1BzJfVhzL5at3yjCUcpztIEV1SbYFVc8dgEp64E/JZ7yK2gtUWY2 1w2YQRcrkg8jALXtH2+0FBnk34Njct7+G/f6LIDcvZiExNcCUzmIdRxb+mWv6g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=D+VAgiQA; 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.30 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=D+VAgiQA; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: 127D82C325 X-Spam-Score: -1.30 X-Migadu-Scanner: scn0.migadu.com X-TUID: IiwltwMlqNhK Hi, Am Mittwoch, den 29.09.2021, 15:17 +0200 schrieb zimoun: > Hi, > > On Wed, 29 Sept 2021 at 12:10, Liliana Marie Prikler > wrote: > > > Perhaps we're bikeshedding, but you started to shed the bike when > > you chose to move this procedure to (guix packages) rather than > > implementing one of Mark's suggestions in [0]. I do think we > > should allow for bikeshedding comments from both sides if that is > > the case. > > I do not have time to bikeshed. :-) (Even if I like to practise it. > ;-)) > > (Note that Mark agreed on my proposal as a variant of one of their > suggestions [0].) > > 0: While Mark did agree to that, I still think that (guix packages) is the wrong location for this procedure. Multiple reviewers can hold different opinions on that matter. > > I don't think #50515 is "perfect as-is", though. Mark's (1) > > suggestion was to put computed-origin-method into its own module, > > which is the same as my long-term position. Mark suggested a > > short-term fix (2) of still comparing by eq?, which I believe you > > dismissed for the wrong reasons. Yes, you would still need to > > check the promise, but you wouldn't invert said check, i.e. you > > would still first look for the method and then assert that the uri > > makes sense. I think it is safer to err on the side of > > conservatism here rather than claim that this > > code will work for future computed-origin-esque methods. > > Maybe. Well, I commented there [1], reworded here: > > The option (1) with its own module means make computed-origin-method > public which implies a lengthy discussion, therefore it is not an > option for me. We agree an option (1), I guess. ;-) From my point > of view, the long-term solution is to improve snippet and remove this > computed-origin-method; not make it public. I personally think there are certain cases where it would make sense to compute origins, but they are not widely applied because computed- origin-method is hidden and clunky. For instance, there are several packages, that pull in extra origins as inputs, which could however be argued to be part of the source closure. Again, there is room to bikeshed far and wide here and all we can agree to currently is that we need some solution long-term. > Perhaps I am wrong about option (2) -- my claim is that > computed-origin-method is *always* used with a promise so it is for > sure an half-baked guess but enough; and it avoids to hard code the > modules from where the packages come from. Therefore, option (2) > does not improve, IMHO. The probability of having a promise when using computed-origin-method is 100%. What is the probability of having computed-origin-method when you see a promise? The answer is: we don't know. We can see from the existing two copies of computed-origin-method, that they use promises, but you could imagine an origin method that takes a promise only as part of its input and then transforms it in some way under the hood. You could also imagine a different computed-origin-method that is actually thunked or uses a raw gexp. > For sure, I am right about this [1]: > > --8<---------------cut here---------------start------------->8--- > However, I would not like that the sources.json situation stays > blocked by the computed-origin-method situation when sources.json is > produced by the website independently of Guix, somehow. :-) > --8<---------------cut here---------------end--------------->8--- > > because it is exactly what it is: blocked by the > computed-origin-method situation. > > 1: Sure, I agree that we need to divorce these discussions if this one is going to take longer – which from the looks of it, it is. > > Instead of doing either (1) or (2), you opted for your own solution > > (3), which is to put this method into (guix packages). In my > > personal opinion, this is a half-baked solution, because it puts > > computed-origin-method into the (guix ...) without addressing any > > of the more fundamental issues raised by Mark. If you really, > > really can't put this into its own module, then I'd at least > > suggest (3a), which is to put it into (gnu packages) instead. That > > way, the definition is at least closer to where it's used and it's > > clearer that it's a hack to package certain things, not a core part > > of Guix. Perhaps you can even make use of it without needing to > > rebuild the guix package in [2/2], but don't quote me on that. > > All the solutions are half-baked! :-) Also, generating this > sources.json using the website is half-backed at first. ;-) > > Options (1) and (2) are more half-baked than my initial submission > (3) (guix packages) or (3a) (gnu packages), IMHO. I don't think option (1) is half-baked, but it does entail making computed-origin-method somewhat public API, which would need more careful review than initially assumed. (2) is half-baked indeed, but because it is minimal effort. Instead of touching the modules in which the definitions are made, it just references them. > About update guix package [2/2], it has to be done, IIUC. The file > sources.json contains what the package guix provides, not what the > current Guix has. The website -- built using the Guile tool haunt -- > uses Guix as a Guile library. Maybe I miss something. What I was trying to say was that you wouldn't need to rebuild the guix package before applying the 50515 changes, which this one seems to require. Again, I'm not 100% sure that's the case, but IIUC (gnu packages) is its own realm in this regard. > > For the right amount of incremental change, I'd suggest the > > following: Try to see whether you can do with computed-origin- > > method in (gnu packages) and without rebuilding the guix package, > > and if so, submit a > > This is what I suggested earlier ;-) [2]: send a v2 moving to '(gnu > packages)' instead and rename to 'compute-origin'. Although I > disagree on (gnu packages). :-) > > I need explanations if rebuild the guix package is not necessary. > > 2: I don't think a rename is necessary if we want a "quick and dirty" version, this suggestion was rather made in the intention that it would be public API. However, if you like the naming choice, feel free to apply it. > > If you are also interested in the more long-term discussion of > > allowing computed origins into the (guix) tree, I suggest sending a > > v2 patch to this thread, which creates a new module, adds > > documentation, and so on, and so forth, and also link to it on > > guix-devel. For the time being, this v2 should also refrain from > > touching anything that uses the current computed-origin-method, as > > that can be addressed in rather simple follow-up commits, > > particularly if we also implement a #50515-v2 > > before. Then we can fully use this to bikeshed about making it a > > verb and what not. > > For long-term, the road seems to improve the 'snippet' mechanism, not > make computed-origin-method public, IMHO. I do have some opinions on that, but I'll type them out in response to Ludo, so as to not repeat myself too often. Cheers