From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id oMm3BiVrVGH9fwAAgWs5BA (envelope-from ) for ; Wed, 29 Sep 2021 15:33:25 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QCdGAiVrVGGDKwAAbx9fmQ (envelope-from ) for ; Wed, 29 Sep 2021 13:33:25 +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 4CF83328FC for ; Wed, 29 Sep 2021 15:33:24 +0200 (CEST) Received: from localhost ([::1]:34390 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVZi7-0005Vq-4w for larch@yhetil.org; Wed, 29 Sep 2021 09:33:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42280) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVZTG-0000HR-7S for guix-patches@gnu.org; Wed, 29 Sep 2021 09:18:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:36524) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mVZTF-00059l-UQ for guix-patches@gnu.org; Wed, 29 Sep 2021 09:18:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mVZTF-0001wF-QM for guix-patches@gnu.org; Wed, 29 Sep 2021 09:18:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#50620] [PATCH 1/2] guix: packages: Document 'computed-origin-method'. Resent-From: zimoun Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 29 Sep 2021 13:18: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: Liliana Marie Prikler Cc: Mark H Weaver , 50620@debbugs.gnu.org Received: via spool by 50620-submit@debbugs.gnu.org id=B50620.16329214547415 (code B ref 50620); Wed, 29 Sep 2021 13:18:01 +0000 Received: (at 50620) by debbugs.gnu.org; 29 Sep 2021 13:17:34 +0000 Received: from localhost ([127.0.0.1]:48070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVZSo-0001vX-9I for submit@debbugs.gnu.org; Wed, 29 Sep 2021 09:17:34 -0400 Received: from mail-qv1-f54.google.com ([209.85.219.54]:36468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVZSi-0001vE-Ph for 50620@debbugs.gnu.org; Wed, 29 Sep 2021 09:17:32 -0400 Received: by mail-qv1-f54.google.com with SMTP id jo30so1417406qvb.3 for <50620@debbugs.gnu.org>; Wed, 29 Sep 2021 06:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oX4U24EgJxf3a/X88JZ6ful5kvXu+m67M3u51iKaE8M=; b=REzmL5Fc/hgfMGfBqfGGHSwm0pZTwlR+xRsuSl0bxnWoAiRwajjwDvkPn/ERpXvho1 SwLt9f0ZLyxjeZ6cSexl+NlkpuqFCCIDdwdVB7j4biFJxHZbdGtn6huvE3HJ7/uMCZMo e3VOWziEXVhtFN+o2abXL3FngNSeOPSisIC0FP5qrCA1Y5AZ2bDyXzuj7R5X+qsJnb+N WOJFtwFs8KcJYfJUTyrDrqvcvlPG4GIVi9cv/heGiw4cft115Medxle6VsfCbr5faF/k oHxHaLSdeebt2/6vHJZklEqGh3yt3fcDhPXZh8VjsJnF0s8Tdy6RVGv2AQaYeQ3flpXU hrpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oX4U24EgJxf3a/X88JZ6ful5kvXu+m67M3u51iKaE8M=; b=PyK3ZScErBKw88l8QsHxMwLdk+LtJIC0wAVbARqRD0zLBSJ3eLga4IKHFsx7y+1mI+ Np8B0zIvU8AGaS4VjsdCsFdUetpwEFhq5/lVUVhjAKgRFeizpCr9oNtEsdhbuLctxyHu p3vVAQ4n3vfOJ7N3Z+5VIHxhqhi1sp3bDzXl+mSzwEaAL/f1zpCy95bD8HBmfADijPp4 eIgG4JDTCi1xp+9UUbzh5R4kEpAFdYATzmv2hoNUh6FBkxOjPzxhjRDpsE75WcYltKXf dXyA0m4SrtM52eFbIMxET70Lx1cYheoI3d2wKtphQgbBr2BZ2jfVMScQoANtgRSB8Nrs MZYQ== X-Gm-Message-State: AOAM532tCGZPqHtaARculOKaXPOtF2aVyK1vfRdTW7+GemWsMJXwgTBg EPAHGeJR0BdO4WLpeeHiSeRZo3YCh7b536x5ZqU= X-Google-Smtp-Source: ABdhPJxbg6mA+CDGhbi7Umpn1uOL+/TEzN7xKxAcZQM6tNVY++kUNolY2u1ziAvPGDK8DZVMO9FrojRu2MBSH0+DyPE= X-Received: by 2002:ad4:484a:: with SMTP id t10mr2943648qvy.55.1632921442215; Wed, 29 Sep 2021 06:17:22 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <56dcce10a751153d89f515028cd18c9125f6b84f.camel@gmail.com> From: zimoun Date: Wed, 29 Sep 2021 15:17:10 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" 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=1632922404; 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: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=oX4U24EgJxf3a/X88JZ6ful5kvXu+m67M3u51iKaE8M=; b=i+ZdjCOc6cz17qeITNaZsL87pirbHiJ1KGUZPGfYYUrFRBZ8ex9ZcAojzy8bqa+d6krlUH b4xKGtHFoQ/+6J6zDJJfFO2s17rcD5cviV083U9TqF+xVOtPBofHUEuok5gFOB66uyp74C YfHKLU8uavAQF8FkNaMZfqidb6o3pabeHXHX/9yat4cikegojxeFxR5qDmb2j7DWfHOzI8 WzjTpdEI9zkNvJYf7hQB1mzOtD8fQW+tm8J79yVi2ZFDbvasWauUIw7CkBrJWsQx7+QkRm qEN+DAGSCGj+0IxbzZff1WKf+hQ/K666C1bQ8CDcDYXmLIfnZRvPYuu45AgjVA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632922404; a=rsa-sha256; cv=none; b=fzoTJVGKzP4x0bkuLHwr6rhKu3KHlgPIWgAdKi5W7b6fS74xfjka4hCg+9RitaZWOtHcXl Kt+XwE9ePOVhXwmDgHvOWv/N+FZY+lL2V/BTmqz+4dneUl+dWtP4i7NMECJ1BM0J5792cj RvKz5kV8/VEWWprbNIRRA++X/+wyrMMUNEhwrpZ9kuJit+DB8f/xrSfkaVRpUCagCh9qmk 8Exgg2+nMFLivFk+Wa5HMxU8eHTevuvqsFiTNTTTqom9Hrex45rYyb4Xdi0TrDnEw1/0sW s6j1RxR2YfGFp6LWK0pcDh31KMlTVWJv03OgBJ1bmvkhECsXR9JboLEcV6VUpA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=REzmL5Fc; 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-Spam-Score: -1.30 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=REzmL5Fc; 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: 4CF83328FC X-Spam-Score: -1.30 X-Migadu-Scanner: scn0.migadu.com X-TUID: eJJXgB/+1J1F 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: > 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. 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. 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: > 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 still think that (guix packages) is better than (gnu packages). Maintainers, what do you think? 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. > 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: > 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. All the best, simon