From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id OBVwFZU11mGGOAAAgWs5BA (envelope-from ) for ; Thu, 06 Jan 2022 01:19:33 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id QEgfEpU11mEH5wAAauVa8A (envelope-from ) for ; Thu, 06 Jan 2022 01:19:33 +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 D3973351C9 for ; Thu, 6 Jan 2022 01:19:32 +0100 (CET) Received: from localhost ([::1]:49576 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5GVA-0002S7-1P for larch@yhetil.org; Wed, 05 Jan 2022 19:19:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5GUy-0002Ry-Mh for guix-devel@gnu.org; Wed, 05 Jan 2022 19:19:20 -0500 Received: from [2a00:1450:4864:20::442] (port=35626 helo=mail-wr1-x442.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5GUw-0000DC-2n for guix-devel@gnu.org; Wed, 05 Jan 2022 19:19:20 -0500 Received: by mail-wr1-x442.google.com with SMTP id j18so1503594wrd.2 for ; Wed, 05 Jan 2022 16:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=NKVC+MvXcJ+BgyYqWw7mTy/ZybM0KaABpdSgV57faqk=; b=Nq/HjwrKJRCt3qPyOpXIBB1TQqxtpzonIKpmUlxPHSqrxYSDl2Lw2aCLvVh4fB+15h Mdz1teAJg4vm1NfxLJTnl4ZcNYad82Rn94li9gDhtoC4jAQS0x9IxQZ5JfyoU0lJ2Ccp b4FZxDPKVUxBzzuEhhtZmNEpuWFlE67jAs/QzV5J9IEXNTiYfLIEvaybw1aMBKzTTOaK TC0Bw174hxr10QUa9DDmejrUPpHyPNPjJ8Bj3bU0+y67I7YN0orlFCfRxRh0wGQIKx4B r37XtwE0obaH2oospf6gN39qhcAtmOIjfiUV6T4/LbmOpj0U789kegekM3qLDdTt0ngk 34LQ== 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:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=NKVC+MvXcJ+BgyYqWw7mTy/ZybM0KaABpdSgV57faqk=; b=umrZ1txKd9xFhRED5mzaVLIHGYYHe2FEAG2uKtgt98USxvUSEG8XRvbnC+hQ5Te2j5 wUmdoFeZUwujxMsYalWM0s4/cUzJVQAoNQolncGvZmuURm9JuLaEw9mHESxYcBktQqgM 1reo4XLAYZBk1Zt6urKQ3uKwUB17KLmBN8sJ0nWdz9MdZvss84D3JAwxKKgUcLdH8a/k i1kxknP/ni/NPInlYQQISiQwy19ATnPWoTe9t7plYBlndBOWvWV4ioMCW+ZKR7ApzyfH XkY9CHfldP4GwzTeb5C8T3vkmhFwwO1hRslB0+pyJDtg6ByNxDlM/dKLyvMVhjMKRgNe DQFw== X-Gm-Message-State: AOAM532BD9aEXec/boWLWiKAMh9U0iCMFYQnZxi+q55DL7ErArua+hOg hTyOAUdQ6l33h2BhFbDTwk0Yk5/wJXjX5Q== X-Google-Smtp-Source: ABdhPJxou9UK3DrWMKZsGQKHb0OoSEYXr8ExtRovqFxXmVbEP4nPtGKLIsuhmies8Hsc0zWWNXPNRg== X-Received: by 2002:adf:d1ef:: with SMTP id g15mr50205328wrd.198.1641428356206; Wed, 05 Jan 2022 16:19:16 -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 k10sm412660wrz.113.2022.01.05.16.19.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 16:19:15 -0800 (PST) Message-ID: <9781ffb5ec81b2d7c58dd171239510e27eef3c79.camel@gmail.com> Subject: Re: RFC: new syntax for inline patches From: Liliana Marie Prikler To: Ricardo Wurmus , guix-devel@gnu.org Date: Thu, 06 Jan 2022 01:19:13 +0100 In-Reply-To: <87ee5ne7z5.fsf@elephly.net> References: <87ee5ne7z5.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::442 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::442; envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x442.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: , 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=1641428372; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=NKVC+MvXcJ+BgyYqWw7mTy/ZybM0KaABpdSgV57faqk=; b=SEee17d3WEPG/w/NVAbvcpZOFHLtCSijPZzJ7gv08FR3UKxRgarbc6EmAQOZMzagynHTkI 9achCHSNX/ezsqTycKLnRZC8SIcmq/8+Iw01tpvLiWNe35NvSmQ83ORmbMWJNsH3m6TEIJ PEtI5chBRtvfMBg88EZ+1iTFuuoBl0zz64T/u8XoImTB7f4uSI4ZappC+YbXZZTAJX+2xb Lt+KyPVFGpEF2hMjGxkFm/R0t+/NQCnKbNNVwTzP17lXnEkfpX8IYNaEWv4bd/8WmhBX/l tB5CqnxkLQDeIvpknTbfMpS2reEGtWeWgbb0HprCzll1obnT3lrwEYnj3Nw2LQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641428373; a=rsa-sha256; cv=none; b=DkvUwnpkv5EQ87oUFXq5tNVfAL8iJ+bC9kB5O10FJBLfPwMf/e0mxye7mhob4gr9HqNvHx DQoF2gEZ0S8zgvrDzQ9Qe48F8WHp01B8QEGilcoHajMsLj5orkjlVs0uZShGYov8i+Gjen 7Jfq2LAGvz9XCEJ2nFu+A0sPXLqcSKTGubUXgeTPdJuPoGXvmWbG8kvJBaTUmTZokWDhgn LnekbM9S+bxbUU3zn0RuAv1YAT4k250uip5dA4M5cddqEhKrZ5pdGHCnOpMri8TpXkI7e5 cLbJOq35HXvlQBPOznFHDMK2z0DQtQhKlLhdxPcvAiXDZJKFAxNl/nx+fqebUA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Nq/HjwrK"; dmarc=pass (policy=none) header.from=gmail.com; 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: -4.30 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Nq/HjwrK"; dmarc=pass (policy=none) header.from=gmail.com; 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: D3973351C9 X-Spam-Score: -4.30 X-Migadu-Scanner: scn1.migadu.com X-TUID: j7hCFBb5khYq Hi Ricardo, Am Dienstag, dem 04.01.2022 um 17:50 +0100 schrieb Ricardo Wurmus: > Hi Guix, > > does this pattern look familiar to you? > >   (arguments >     (list >     #:phases >     '(modify-phases %standard-phases >       (add-after 'unpack 'i-dont-care >         (lambda _ >           (substitute* "this-file" >             (("^# some unique string, oh, careful! gotta \\(escape\\) > this\\." m) >              (string-append m "\nI ONLY WANTED TO ADD THIS > LINE!\n")))))))) > > This is a lot of boilerplate just to add a line to a file.  I’m using > “substitute*” but actually I don’t want to substitute anything.  I > just know that I need to add a line somewhere in “this-file”. Now many of these substitute*s are actually sane. E.g. those which match the beginning of a defun in Emacs terms. However, there for sure are cases in which I think "when all you have is a substitute*, every problem you have starts to look like... oh shit, I can't match this multi-line string, back to square 0". > CMakeLists.txt I feel your pain. > We have a lot of packages like that.  And while this boilerplate > pattern looks familiar to most of us now, it is really unclear.  It > is imperative and abuses regular expression matching when really it > should have been a patch. Now imperative is not really the bad thing here, but I'll get to that a little bit later when discussing your mockup. I do however agree that it's too limited for its task. > There are a few reasons why we don’t use patches as often: > > 1. the source code is precious and we prefer to modify the original > sources as little as necessary, so that users can get the source code > as upstream intended with “guix build -S foo”.  We patch the sources > primarily to get rid of bundled source code, pre-built binaries, or > code that encroaches on users’ freedom. > > 2. the (patches …) field uses patch files.  These are annoying and > inflexible.  They have to be added to dist_patch_DATA in > gnu/local.mk, and they cannot contain computed store locations.  They > are separate from the package definition, which is inconvenient. > > 3. snippets feel like less convenient build phases.  Snippets are not > thunked, so we can’t do some things that we would do in a build phase > substitution.  We also can’t access %build-inputs or %outputs.  (I > don’t know if we can use Gexps there.) Both patches and snippets serve the functions you've outlined in 1. Now 2. is indeed an issue, but it's still an issue if you include patch as native input as well as the actual patch file you want to apply (assuming it is free of store locations, which can be and has been worked around). > It may not be possible to apply patches with computed store locations > — because when we compute the source derivation (which is an input to > the package derivation) we don’t yet know the outputs of the package > derivation.  But perhaps we can still agree on a more declarative way > to express patches that are to be applied before the build starts; > syntax that would be more declarative than a serious of brittle > substitute* expressions that latch onto hopefully unique strings in > the target files. > > (We have something remotely related in etc/committer.scm.in, where we > define a record describing a diff hunk.) > > Here’s a colour sample for the new bikeshed: > >   (arguments >     (list >       #:patches >       #~(patch "the-file" >          ((line 10) >           (+ "I ONLY WANTED TO ADD THIS LINE")) >          ((line 3010) >           (- "maybe that’s better") >           (+ (string-append #$guix " is better")) >           (+ "but what do you think?"))))) Now this thing is again just as brittle as the patch it encodes and if I know something about context-less patches then it's that they're super not trustworthy. However, have you considered that something similar has been lying around in our codebase all this time and 99% of the packages ignore it because it's so obscure and well hidden? Why yes, of course I'm talking about emacs-batch-edit-file. Now of course there are some problems when it comes to invoking Emacs inside Guix build. For one, not every package has emacs-minimal available at build time and honestly, that's a shame. Even then, you'd have to dance around and add emacs-utils to enable it. And after that? You code Emacs Lisp in the middle of Guile code! Now certainly, this UI can be improved. Particularly, I'd propose a set of monadic functions that operate on a buffer in much the same way Emacs does. Now we wouldn't need to implement all of Emacs in that way (though we certainly could if given enough time). Basic primitives would be the following to name a few: search-forward, re-search-forward, goto-char, forward-line, point-min, insert, beginning-of-line, end-of-line, delete-region, point. Of course we could rename them to be more guily, but that's a minor concern imo. Notice how I omitted find-file and save-buffer, because that should be taken care of by the monad. WDYT, should we pursue that? Or should we just add an Emacs to our native inputs? :P