From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 09:17:34 2021 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: Subject: Re: [PATCH 1/2] guix: packages: Document 'computed-origin-method'. To: Liliana Marie Prikler Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50620 Cc: Mark H Weaver , 50620@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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