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.