From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 eKa8GlGB1GEZhQAAgWs5BA (envelope-from ) for ; Tue, 04 Jan 2022 18:18:09 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id IJ8eGFGB1GFE6QAA9RJhRA (envelope-from ) for ; Tue, 04 Jan 2022 18:18:09 +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 BFB1434945 for ; Tue, 4 Jan 2022 18:18:06 +0100 (CET) Received: from localhost ([::1]:38198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4nRl-0001Hq-TK for larch@yhetil.org; Tue, 04 Jan 2022 12:18:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56148) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4nRC-0000L2-EE for guix-devel@gnu.org; Tue, 04 Jan 2022 12:17:30 -0500 Received: from sender4-of-o51.zoho.com ([136.143.188.51]:21152) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4nR8-0000qe-T1 for guix-devel@gnu.org; Tue, 04 Jan 2022 12:17:30 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1641316642; cv=none; d=zohomail.com; s=zohoarc; b=LV5B8+ucbiq6Y8iCbJ+cc5NHRMO4L5i2f7aXXa9eKBqviKRJPLSINFZxSsoxaf91LGuBs7EOkXgXYmhcC18j9+a8djVAUeOLEPh3cC72ZasYNYwpVK0s1DayUxWl3rJK+Rqjkbkj3XFS4sIfsEA3974YUyzTFF+r8bjCFzayZRY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1641316642; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To; bh=lHOnPO8r4aQsCdwX4EsgG1ixKjjT5pNYEZA5w7rSyu0=; b=YN8NTdmstqtsN3ZBi447EiY2aVnFVT+n5MyNJ9FA6hJa8HQnr/HCz/8DaQHuSdzmTv+XvHEI8RTIRMAL1TPeo8/m9JntlbSDtqSyx4RoAEsya9/F6ph7dhL8mgLNYKY9bLi1UJaRw39SSAuwvXBaNWJJTo+gdFU66gcrm9p6RRk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1641316642; s=zoho; d=elephly.net; i=rekado@elephly.net; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=lHOnPO8r4aQsCdwX4EsgG1ixKjjT5pNYEZA5w7rSyu0=; b=DNiECh2Nc3+LTYjeUOCxNSHC5ZJb3LBj5F3VeNoSdGk2YxCxLgvxkRJiks1ENexT qTh8h20F7g5B731971wzetlEcINrGYatnNiOYUSDo7Eymq62azjBTPhZObeK54+5OBX bfkpXeJ9pUDNHKAOEgV1oWG3fFOSFhESV0iY3Rl8= Received: from localhost (p54ad4c55.dip0.t-ipconnect.de [84.173.76.85]) by mx.zohomail.com with SMTPS id 1641316641497855.1825771612554; Tue, 4 Jan 2022 09:17:21 -0800 (PST) User-agent: mu4e 1.6.10; emacs 27.2 From: Ricardo Wurmus To: guix-devel@gnu.org Subject: RFC: new syntax for inline patches Date: Tue, 04 Jan 2022 17:50:31 +0100 X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Message-ID: <87ee5ne7z5.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.51; envelope-from=rekado@elephly.net; helo=sender4-of-o51.zoho.com X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641316686; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=lHOnPO8r4aQsCdwX4EsgG1ixKjjT5pNYEZA5w7rSyu0=; b=DX9buzGZiIw73uwIVlH5cmoFyUDDIg+gngCoyXBkZD2y4kObhawipwu4xpmqquJtzONVZG FwczQzXwtFL9Acq8gNJFDUbxi9wBvAEVe66q3WBMyZwbMkOBEKDaTVBimZnyrdUkiamGdN H54RzL6FdefBC7uKHdGAdsrcvxw5X9gcrj2x/lxYP2rhMpTszM8S+gV/bgp7PAddmWinoT J/mbJ+Wg8ME8AciHfFImVl/jB0gVbeaiYrysiEoXAkIjqcF9+/LMm9M9oZnh48yJap5Kwv sGgd8bNYmycJ7Rmt8IBKSaYH75an6qxsC9S4mH7hM4VhoPi8REClSUZkkKEBEQ== ARC-Seal: i=2; s=key1; d=yhetil.org; t=1641316686; a=rsa-sha256; cv=pass; b=kfVPmQLr6mIS6n++RgiFTJpmb41//7jwM0/ryrHsqSqxMOm90B+QJGSW4UbzKWu15XxO8o IhRf1UR6RE1mQLjL528AdQg7zE2i3XZfIlWRnvxcZB3oCIhc5BJ47IIK8BIlMY2LTjSKeQ peVb9vPjsRLIN6N4gku/GbMlCULu0P1Ie4xilrONbqVSuUZKZJeDGCfaQJDEi7Kwoz9N8a rnysuXKNBC0n4oAiILQWXAR1TSAAPxuHWCodw09a0Uqhx1op3LU0Wdg1YEQkRekhQY/4kZ K0pOy2EYlBf/TXREeZ99Aga+knM7S3BvKscc/2yXkJOn+JpiCJjqi8tP7U+o1A== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b=DNiECh2N; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=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: -3.83 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b=DNiECh2N; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=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: BFB1434945 X-Spam-Score: -3.83 X-Migadu-Scanner: scn1.migadu.com X-TUID: +X9ssnRhpxZP 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=E2=80=99m usi= ng =E2=80=9Csubstitute*=E2=80=9D but actually I don=E2=80=99t want to substitu= te anything. I just know that I need to add a line somewhere in =E2=80=9Cthis-file=E2=80=9D. Or maybe it=E2=80=99s a CMakeLists.txt file that inexplicably wants to down= load stuff? I should patch that file but it=E2=80=99s a multi-line change. So = I=E2=80=99m trying to do the same as above with several different anchor strings to comment out lines. 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. There are a few reasons why we don=E2=80=99t 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 =E2=80=9Cguix build -S foo=E2=80=9D. We patch the s= ources primarily to get rid of bundled source code, pre-built binaries, or code that encroaches on users=E2=80=99 freedom. 2. the (patches =E2=80=A6) 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=E2=80=99t do some things that we would do in a build pha= se substitution. We also can=E2=80=99t access %build-inputs or %outputs. (I = don=E2=80=99t know if we can use Gexps there.) I feel that the first point is perhaps a little overvalued. I have often felt annoyed that I had to manually apply all this build phase patching to source code obtained with =E2=80=9Cguix build -S=E2=80=9D, but = I never felt that source code I got from =E2=80=9Cguix build -S=E2=80=9D was too far rem= oved from upstream. It may not be possible to apply patches with computed store locations =E2= =80=94 because when we compute the source derivation (which is an input to the package derivation) we don=E2=80=99t 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=E2=80=99s 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=E2=80=99s better") (+ (string-append #$guix " is better")) (+ "but what do you think?"))))) --=20 Ricardo