guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: new syntax for inline patches


From: Liliana Marie Prikler
Subject: Re: RFC: new syntax for inline patches
Date: Thu, 06 Jan 2022 09:12:03 +0100
User-agent: Evolution 3.42.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]