From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id sNy4N/tD1mF1fwAAgWs5BA (envelope-from ) for ; Thu, 06 Jan 2022 02:20:59 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id LY1WNPtD1mHVfgAAauVa8A (envelope-from ) for ; Thu, 06 Jan 2022 02:20:59 +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 972AD434FD for ; Thu, 6 Jan 2022 02:20:59 +0100 (CET) Received: from localhost ([::1]:39632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5HSc-0001yL-Ns for larch@yhetil.org; Wed, 05 Jan 2022 20:20:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5HSM-0001yC-Rq for guix-devel@gnu.org; Wed, 05 Jan 2022 20:20:43 -0500 Received: from mail2.fsfe.org ([213.95.165.55]:37880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5HSJ-0005EI-Iv for guix-devel@gnu.org; Wed, 05 Jan 2022 20:20:41 -0500 From: Jelle Licht DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsfe.org; s=2021081301; t=1641432032; h=from:from: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; bh=ybCJo2AOUYXv5hI4RzGxKk2CiHFhBG83kWQ/BmLaNhg=; b=cg+H9ISFWeNJvDZMeHrxgLJLiTR1YYPJdZ1EHObP0CTFlucHSPMYQcHZOXJPmgPU4eAQHB h6LM+lvBP6zJ9Z1KU58ACaokgE6BdVipP8mEAD0oDTlcvlUJzxxzuhB2LYvmDW1YjPGuJq 5h407ysH9hR4oJ1h0UziI8Um/uPMEOA= To: Liliana Marie Prikler , Ricardo Wurmus , guix-devel@gnu.org Subject: Re: RFC: new syntax for inline patches In-Reply-To: <9781ffb5ec81b2d7c58dd171239510e27eef3c79.camel@gmail.com> References: <87ee5ne7z5.fsf@elephly.net> <9781ffb5ec81b2d7c58dd171239510e27eef3c79.camel@gmail.com> Date: Thu, 06 Jan 2022 02:20:30 +0100 Message-ID: <861r1lacdd.fsf@fsfe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=213.95.165.55; envelope-from=jlicht@fsfe.org; helo=mail2.fsfe.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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=1641432059; 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=ybCJo2AOUYXv5hI4RzGxKk2CiHFhBG83kWQ/BmLaNhg=; b=ZQkNj1dpOc1B+446GmWYTCTQ0yYK0FF8wZRLfTLid4uULyJJYGsWGHP4gYIZTx3FirKWFU eh7clWoFttqIo+Dv0D0bfqZyts3tvPqbsV1FcHaC11vKbG3KkWwQ1s2+zup/KvArTVfIeE NRLOqgXFRqOxOU3c6bUckZn7/7jZgVYOvAJI3Vt6HHCTsfPWZP1l+Zcz4mUosj3l726TWc gPKBCc4203DWvlOXxneJfDW16GyLpLJy6tIZEWfxnMyMbACadnYiqI8l4EsO2Akubq9y2Z byxKloXzpGrbvr3GNyYITofR5Ty3gbLEKhGBv7BHChss57gbM6w0k+iCdf0lUg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641432059; a=rsa-sha256; cv=none; b=m9jIoiHrxX9bwQoMllOptRPyjbYGPiFgz8neaC2yb2DeNSnI5+DVU1N0cvPocHKS0aW3cg 7YuBOivn3B01dp4tlAjO/Jp6aK6ZZ9/HEAY3aBkvV251nRHDny6h/F/5ahz7VLBt90OV9h P32IBKfaSBHWWfPJnB9m2cHgPNr+U0EdzH/oUzAdBL0YpDJt3785pMQPZQKeDBN3sTPEjI S2eeqT7MKpZOTK+B2e/RCQgHrkNZ9GgbAJiYxgtWyrJ5/6nn2gLkq5PkLN1Y0UlE3mRO5a todiIs0tbMOQxH4EJHE5ELL9b2E/jp8eaSLoZxscy0G5UzQjTa8Njv2199fqYw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021081301 header.b=cg+H9ISF; dmarc=pass (policy=none) header.from=fsfe.org; 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: -7.40 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021081301 header.b=cg+H9ISF; dmarc=pass (policy=none) header.from=fsfe.org; 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: 972AD434FD X-Spam-Score: -7.40 X-Migadu-Scanner: scn0.migadu.com X-TUID: O+zQ/ZYKDhjl Liliana Marie Prikler writes: > Hi Ricardo, > > Am Dienstag, dem 04.01.2022 um 17:50 +0100 schrieb Ricardo Wurmus: >> Hi Guix, >>=20 >> does this pattern look familiar to you? >>=20 >> =C2=A0 (arguments >> =C2=A0=C2=A0=C2=A0 (list >> =C2=A0=C2=A0=C2=A0 #:phases >> =C2=A0=C2=A0=C2=A0 '(modify-phases %standard-phases >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (add-after 'unpack 'i-dont-care >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (lambda _ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (substitute* "thi= s-file" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (("^#= some unique string, oh, careful! gotta \\(escape\\) >> this\\." m) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= (string-append m "\nI ONLY WANTED TO ADD THIS >> LINE!\n")))))))) >>=20 >> This is a lot of boilerplate just to add a line to a file.=C2=A0 I=E2=80= =99m using >> =E2=80=9Csubstitute*=E2=80=9D but actually I don=E2=80=99t want to subst= itute anything.=C2=A0 I >> just know that I need to add a line somewhere in =E2=80=9Cthis-file=E2= =80=9D. > 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.=C2=A0 And while this boilerplate >> pattern looks familiar to most of us now, it is really unclear.=C2=A0 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=E2=80=99t use patches as often: >>=20 >> 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.=C2=A0 We = patch the sources >> primarily to get rid of bundled source code, pre-built binaries, or >> code that encroaches on users=E2=80=99 freedom. >>=20 >> 2. the (patches =E2=80=A6) field uses patch files.=C2=A0 These are annoy= ing and >> inflexible.=C2=A0 They have to be added to dist_patch_DATA in >> gnu/local.mk, and they cannot contain computed store locations.=C2=A0 Th= ey >> are separate from the package definition, which is inconvenient. >>=20 >> 3. snippets feel like less convenient build phases.=C2=A0 Snippets are n= ot >> thunked, so we can=E2=80=99t do some things that we would do in a build = phase >> substitution.=C2=A0 We also can=E2=80=99t access %build-inputs or %outpu= ts.=C2=A0 (I >> don=E2=80=99t know if we can use Gexps there.) > Both patches and snippets serve the functions you've outlined in 1.=20 > 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 >> =E2=80=94 because when we compute the source derivation (which is an inp= ut to >> the package derivation) we don=E2=80=99t yet know the outputs of the pac= kage >> derivation.=C2=A0 But perhaps we can still agree on a more declarative w= ay >> 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. >>=20 >> (We have something remotely related in etc/committer.scm.in, where we >> define a record describing a diff hunk.) >>=20 >> Here=E2=80=99s a colour sample for the new bikeshed: >>=20 >> =C2=A0 (arguments >> =C2=A0=C2=A0=C2=A0 (list >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #:patches >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #~(patch "the-file" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((line 10) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (+ "I ONLY WANTED= TO ADD THIS LINE")) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ((line 3010) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (- "maybe that=E2= =80=99s better") >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (+ (string-append= #$guix " is better")) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (+ "but what do y= ou 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. What do you mean here, with 'brittle' and 'trustworthy'? Is it the fact that line numbers are hardcoded, compared to the substitute* approach? > 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.=20 > Notice how I omitted find-file and save-buffer, because that should be > taken care of by the monad. I'd prefer something that is declarative in the sense that the 'how' is abstracted away, with a focus on the 'what'; both Ricardo's proposal and emacs-batch-edit-file do this, and to a much lesser extent the current substitute* mess. 'Navigation primitives' as you propose here are perhaps abstract in the technical sense of the phrase, but still indicate to me a focus on the 'how' instead of the 'what'. Another nice property of keeping these concerns separated is that it should be easy (or at least possible) to later reimplement e.g. Ricardo's proposal on top of such monadic primitives. Doing it the other way around seems much less fun, if even feasible at all :-). > WDYT, should we pursue that? Or should we just add an Emacs to our > native inputs? :P At the risk of escalating this perhaps-not-totally-serious proposal, I wrote some snippets that should allow one to write elisp in g-expressions using guile's built-in elisp reader + some hacks to serialize guile's internal representation of parsed elisp to valid elisp again. - Jelle