From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id y1A4LjSm1mEEBgEAgWs5BA (envelope-from ) for ; Thu, 06 Jan 2022 09:20:04 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id kD9GJjSm1mHp7AAAG6o9tA (envelope-from ) for ; Thu, 06 Jan 2022 09:20:04 +0100 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 4F88412373 for ; Thu, 6 Jan 2022 09:20:04 +0100 (CET) Received: from localhost ([::1]:56422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5O0B-0007z6-Dl for larch@yhetil.org; Thu, 06 Jan 2022 03:20:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5Nsh-0002CC-Af for guix-devel@gnu.org; Thu, 06 Jan 2022 03:12:20 -0500 Received: from [2a00:1450:4864:20::341] (port=53189 helo=mail-wm1-x341.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5NsW-0005Gc-BU for guix-devel@gnu.org; Thu, 06 Jan 2022 03:12:10 -0500 Received: by mail-wm1-x341.google.com with SMTP id v123so1216218wme.2 for ; Thu, 06 Jan 2022 00:12:06 -0800 (PST) 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=FIgXE6xUVHTnQA13qGf6E2A1R6qWvz+s9q56GKoAM6o=; b=GFFOawX2NCMU2Q6M/JKrs6VAJVafymWm1fAjCuH0JsmNiKSrzSuEPptwQq/w+Xz2Rn ZywJdGPAU4ggtnINgTXce2GLKDEv6T8Y99hWQKco/frr+qoYeDaeHveiquPByt+TIeq1 IAdrCOqyvRTjgPumH2CLvs5QVA7bj8uYMck1SkRLb2ISqbJZjuWsoihUGMg+dPxakCUu hJdW1AsUrz+tsr52OUBY/fPS+m6a+cCQMtN4jVPS8SjdN1xL5Ht7HmikzTys/SOvkdU1 AJHKYp7aAhwSXzLSaP7NSmbI6hbRDkhZbCnVSUGfrDlv31agkFmnMz5yJTwdTKuB1GBQ 3qRg== 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=FIgXE6xUVHTnQA13qGf6E2A1R6qWvz+s9q56GKoAM6o=; b=b4zZi5AsSE7hb0QLMw0RS1TDNVpYTnhFVrCgBBh73NQT/SEiQuhEdtFSQGPRnPFzvg CnlFuJI6/12x5qgU43MZaizrCqsqpm2qrJhlufdNOcbUM/4r/3Sp20eT4IqbbyOfs4Cu /+NF2YDNvudOfk+YPiSSoCIcaVxHOI0hdUFEJZC+bvbTLq9NTYxUvXCCvDcrPqURzZhy yNGP53JHQq8ft7oxIIaM3cMG7CTJOhClLiZtUvAvkpSqSrDff1pA5rq767G9/sNkU6MC cetYWqwZsxqvDBGciFpKvxpM8kVhvCzxFZ0tc0A+UBlAy4QqmcYfTRs+f795FBxRwaDO UGyA== X-Gm-Message-State: AOAM533lE1KMDsmvp+4QlJp0i94n8faErASjxHWFeQDzp9/UbX+Guhcq hOmdOKWn/wf7QX3d70jlnW4= X-Google-Smtp-Source: ABdhPJyVy1ni76s+AArrUso4Q8ERQfIPOwr3Sguafh6O0xnoF1E5QDnTw46i+EqdrgDhuAho8Yn/Qw== X-Received: by 2002:a05:600c:3496:: with SMTP id a22mr6059238wmq.68.1641456725294; Thu, 06 Jan 2022 00:12:05 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id i9sm1382805wrb.84.2022.01.06.00.12.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jan 2022 00:12:04 -0800 (PST) Message-ID: <1cd9957f57ca5294d57591b89839e2755e451c03.camel@gmail.com> Subject: Re: RFC: new syntax for inline patches From: Liliana Marie Prikler To: Ricardo Wurmus Date: Thu, 06 Jan 2022 09:12:03 +0100 In-Reply-To: <87leztba9k.fsf@elephly.net> References: <87ee5ne7z5.fsf@elephly.net> <9781ffb5ec81b2d7c58dd171239510e27eef3c79.camel@gmail.com> <861r1lacdd.fsf@fsfe.org> <91c6c25534e422d893a3dd219633a2e7ff3f1a68.camel@gmail.com> <87leztba9k.fsf@elephly.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::341 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::341; envelope-from=liliana.prikler@gmail.com; helo=mail-wm1-x341.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, 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: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641457204; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=FIgXE6xUVHTnQA13qGf6E2A1R6qWvz+s9q56GKoAM6o=; b=sGnnSptSUNyeosL7RlKAOI77HR0SDiPUwCp+b2hxLnZS4wZClvU25cRJm6RGCA+sDR2OhA w9p/n6tOKeJLXGKToQstcJeaiPPAHRw2V8Iws2Fs4K7pjU9DOWV/oMifAwQVagP3CA/I+d QDCYX4AFzUE3GQDQeNty+6g37+Wx801ogXFTqtLCbw0zz0ZDy8+4O+5winljbIJr5EJr+Z EV+sV0NxoFMw215N8nXn1BvIe4FNEGcUTmm4L+XfG+f55f39uunBvD4Is7SLsmOyvnyR1R klgwKb4xxz8XSp+Vo5kGSym8wprFJpd4RK1nvEn2bpzJBzn/oKUxj3wc07qVbw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641457204; a=rsa-sha256; cv=none; b=uxsvTlmZwEeNabcNv1TLXfgkTtPODHlwgCFLA4/V57pUYCxsYTB9S3Sw4a1PPy0WVnbeRP jijmujrVxs34MNdcdDW1t+3l1VdJjFVp8UnIW56T+lUrLhMDOrCkMyRCimKrIS/FzTWRaw vruwQVLGuyqm4zyGVc7ABWZFELhokDUZDYMsDHlacz/v5FVYn4RB2/QKvkKAS/c0OrueIi CS2QfbdBD1pryV2vEtqxTy/GznE2VEe8a6GMrDrT+UHNLGUaDXfa2JtE7FrD+Rl4dLHBPS uAjbkIg04IutQdjfOjA1WmnZJZehbaTAW9KcUaSk+Csd3Z/SGskegyM+Oscqww== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=GFFOawX2; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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" X-Migadu-Spam-Score: -2.00 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=GFFOawX2; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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" X-Migadu-Queue-Id: 4F88412373 X-Spam-Score: -2.00 X-Migadu-Scanner: scn1.migadu.com X-TUID: Vc3laQAoVfBs Hi Ricardo, Am Donnerstag, dem 06.01.2022 um 08:12 +0100 schrieb Ricardo Wurmus: > So lets take a step back and look at the location and shape of the > bikeshed rather than its color.  Do we agree that it would be lovely > to have a less flexible but declarative pattern to describe changes > to files?  Less flexible than a full-blown editing DSL as that of > Emacs, less flexible than perhaps arbitrary regular expression > replacements as provided by substitute*?  I just think that sometimes > we want to focus on the change itself and not how we get there. I can't say that we do. Look back at Attila's case for plain old diffs. It seems to me that if all you want to encode is a patch file, you ought to use a patch file. That doesn't necessarily entail adding it to origin, however, and I think we can find some agreement if we change the way we write things. > It’s primarily a matter of style and readability.  I think it’s > regrettable to have all these boilerplate build phase shenanigans to > express a simple change in a file.  A large chunk of that is just > boring set up work to be permitted to use “substitute*”, and then the > “substitute*” itself is primarily concerned with an anchor that could > not be much uglier: a regular expression DSL embedded in a string > with double escaping.  Yuck! > > Even something as simple as diff-in-a-string seems more appealing in > some cases than all these “substitute*” expressions. Now X in a string is usually very appealing due to its pretty low barrier for entry. For a long time, I had the custom Ren'py launcher be a big format¹, because that's what worked. However, I've since changed it to an aux-file + substitute*, and that gets my intent across much more clearly. I think we can do something similar for patches. Rather than coding them into the file, we'd have #:patches #~(list #$(locate-first-patch) #$(locate-second-patch)), and a post-unpack phase (let's call it "patch") would take care of applying these patches. If you need store paths, you can write @HERE_COMES_THE_STORE_PATH@ and easily match that in a substitute that runs in a post-pack phase. If you prefer we do so atomically in unpack (i.e. unpack becomes "unpack and apply all #:patches") so as to not change our phase API, that'd also work for me personally. In short, I'd say "yes" to making it easier to apply patches at build time. Currently, you have to add both the patch and the patch program as well as code up your own phase to do so – not ideal. We could lessen that to just making sure patch is in native-inputs if the #:patches keyword is used. Now you still have to adjust dist_patch_DATA and that might be a pain point for maintainers, but in the grand scheme of things it's in my opinion a lesser evil. WDYT? ¹ We need one, because the one supplied by upstream happily loads the same files twice only to then fail with a huge stack trace. I'm not sure if I inadvertently fixed the reason why it loads the same files twice elsewhere, but it's nice to have that control.