From: Efraim Flashner <efraim@flashner.co.il>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel@gnu.org
Subject: Re: RFC: new syntax for inline patches
Date: Wed, 12 Jan 2022 19:56:57 +0200 [thread overview]
Message-ID: <Yd8WaSov6iy7rnob@3900XT> (raw)
In-Reply-To: <87ee5ne7z5.fsf@elephly.net>
[-- Attachment #1: Type: text/plain, Size: 4077 bytes --]
On Tue, Jan 04, 2022 at 05:50:31PM +0100, Ricardo Wurmus wrote:
> 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”.
>
> Or maybe it’s a CMakeLists.txt file that inexplicably wants to download
> stuff? I should patch that file but it’s a multi-line change. So I’m
> 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’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.
It also feels wrong to add a 30 line patch, taking into account the
header bits, to make a 3 line change.
> 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.)
I believe you can leave out the modules line and use a gexp in the
snippet (without the "'(begin" portion )
> 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 “guix build -S”, but I never felt
> that source code I got from “guix build -S” was too far removed from
> upstream.
>
> 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?")))))
I have on at least one occasion stopped myself from trying to use ed (it
IS the standard editor) to apply something that SHOULD BE trivial to
change.
--
Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2022-01-12 17:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 16:50 RFC: new syntax for inline patches Ricardo Wurmus
2022-01-05 8:16 ` Attila Lendvai
2022-01-06 0:19 ` Liliana Marie Prikler
2022-01-06 1:20 ` Jelle Licht
2022-01-06 6:43 ` Liliana Marie Prikler
2022-01-06 7:12 ` Ricardo Wurmus
2022-01-06 8:12 ` Liliana Marie Prikler
2022-01-08 21:34 ` Ludovic Courtès
2022-01-12 18:06 ` Efraim Flashner
2022-01-12 17:56 ` Efraim Flashner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yd8WaSov6iy7rnob@3900XT \
--to=efraim@flashner.co.il \
--cc=guix-devel@gnu.org \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).