From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id eI17KUNIZ2e7NgAAe85BDQ:P1 (envelope-from ) for ; Sat, 21 Dec 2024 22:59:15 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id eI17KUNIZ2e7NgAAe85BDQ (envelope-from ) for ; Sat, 21 Dec 2024 23:59:15 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=qEfabNke; dkim=fail ("headers rsa verify failed") header.d=scratchpost.org header.s=kas202409041115 header.b=NBq7AApF; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734821955; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=YF871viIa7mfge2BspU/akuIe9LTB3khrt0WGsJWlHI=; b=kne4T7TZqn/NzHPF//58odIALUUvN7xEmJsJ6Acx//5V/2NL+ptGol8GH53Va3Tdd3jL5L ZOjhiNuU4Qd//mfQMIDYoovvsShdI45Lww9OXFQxAZ16mt39mv0E9/Xwjd4VNyj+VovJYr FrfvIWxn1cMlFrLQZwkCEotVem1uHOfbm2DC+BrV8cH3lvwi6twcGw5JN2nEp9Zyhefht/ wk8U7w1YJOUt/bcQCfATPikSz85KeKEJ1nfHb8zMb+n/vqFIe7TgHpQ/6pL4AkuT0jHMOr vyYNVPZok5LDBnguFHH4UhrKpKtO62sgfIs3+lTJ442mvGD3jQneIRxXrYDK4g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=qEfabNke; dkim=fail ("headers rsa verify failed") header.d=scratchpost.org header.s=kas202409041115 header.b=NBq7AApF; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734821955; a=rsa-sha256; cv=none; b=hV6pTz0D+d3nLxa9HudStMwCDovB/MVS42BJOsm7M8VzKEIlpcWaomrq1rSiT87PAl3aab PeQ60izXVdPsOhTuW+l6ByvqtQxNu/cUHAguBKPHG8w3G/By74N8EPF2AnC+FJfPjfVskH 7JxS7LdW9+f6TlDp+y4eqo2rKD+r7ZRt2nEioA77In+KJnAxr+A3+oU8WzECJJTr1Q4O5J z5WFi/DrNwNCr2y0mZL3+J8vdJAWGYcN4DE25bNd/v8FnJnE2vRacEWeQCIzZS5RUQJ7Ps EAm8Ri6L1X0aDfNHfzCU4oMd8oblrfOcIK3AH+5O/XwrjgDmfpogay7jRmNy7A== 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 0CA2C103C for ; Sat, 21 Dec 2024 23:59:14 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tP8R7-0000Oc-Tu; Sat, 21 Dec 2024 17:59:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tP8R4-0000OK-GO for guix-patches@gnu.org; Sat, 21 Dec 2024 17:59:02 -0500 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tP8R4-0002Al-7d for guix-patches@gnu.org; Sat, 21 Dec 2024 17:59:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:In-Reply-To:MIME-Version:From:References:To:Subject; bh=YF871viIa7mfge2BspU/akuIe9LTB3khrt0WGsJWlHI=; b=qEfabNke0keUzHKMZgPGqLYv3eP1qoYQ5nL0V4+sDUJzxM6hHTPD0FO7pRgh4NB9569mXp5ooXGWzRGYXqYNI8ANhT+dXZzn/JWM+b2wnVWVcWVV0gZ1AwcSZ7Mni2VdJgY+ekdqnPp6HxAX0/qFMuTUZWX3OOULMqVSBlWFWd/kniEpnoKt9UkKJk+g/0CNP7jZhv14hHugyvDmhbClBU1QPGQ0mv8m3mcDXY0Scz9zUiikviFxaSo7S4fHfVVq9ZbVjWbhNH7I77iVM3ZFsOVNeNFJzOcs+h4JkNbFvDHPAp9nCwCpGZr0TCo74AYHL+mu9PL5NmeC5ZlK8L8CBw==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tP8R4-0005EX-31 for guix-patches@gnu.org; Sat, 21 Dec 2024 17:59:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#72994] manifest.scm and emacs-specific things Resent-From: "Danny Milosavljevic" Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 21 Dec 2024 22:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72994 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: ludo@gnu.org, liliana.prikler@gmail.com Cc: cox.katherine.e+guix@gmail.com, 72994@debbugs.gnu.org, dannym@friendly-machines.com, andrew@trop.in Received: via spool by 72994-submit@debbugs.gnu.org id=B72994.173482188920047 (code B ref 72994); Sat, 21 Dec 2024 22:59:02 +0000 Received: (at 72994) by debbugs.gnu.org; 21 Dec 2024 22:58:09 +0000 Received: from localhost ([127.0.0.1]:48275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tP8QC-0005DH-L3 for submit@debbugs.gnu.org; Sat, 21 Dec 2024 17:58:09 -0500 Received: from dd30410.kasserver.com ([85.13.145.193]:58214) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tP8Q9-0005D7-Qk for 72994@debbugs.gnu.org; Sat, 21 Dec 2024 17:58:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scratchpost.org; s=kas202409041115; t=1734821884; bh=YF871viIa7mfge2BspU/akuIe9LTB3khrt0WGsJWlHI=; h=Subject:To:References:Cc:From:In-Reply-To:Date:From; b=NBq7AApFWbgWSowtSP98n1pSO9Gp5qNJmyzBQ35vXkVKKObhhHGLxPR0xjaJCUuRt yHDv3ejV237C1YVkx+AmbVeFoKtwxGi72dIA2Wb1OiAwN/133w9LIDrlx1iCSdpnuB D0qXGNGgLlvvzve8ub6p9UXwNzujU9YHXiPdp8XuWx+oeeqwMWC/fZiNckfK5/FlmK b8WZHOuKHQsWhAritbKYCfY5WUFaHvRR7TMqtt/GClM7AlC1n9yoRNBjXs3iFpZlPx xITw25gJcTq1Z8pZjsx50CnDLMwD4a2DIzKTrbcI7PPCB+oPcKhJ25jISZQVOOt8cR Z/xVzLwguPisQ== Received: from dd30410.kasserver.com (dd0802.kasserver.com [85.13.143.1]) by dd30410.kasserver.com (Postfix) with ESMTPSA id 96AA91121508; Sat, 21 Dec 2024 23:58:04 +0100 (CET) References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@friendly-machines.com> <87cyl49fbv.fsf@gnu.org> <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@gmail.com> <87zfn3rx8q.fsf@gnu.org> <20241221183335.2740D1120E20@dd30410.kasserver.com> <6913205399a12a20587ef1826a7fa44cc01d8b2a.camel@gmail.com> From: "Danny Milosavljevic" User-Agent: ALL-INKL Webmail 2.11 X-SenderIP: 213.147.164.14 MIME-Version: 1.0 In-Reply-To: <6913205399a12a20587ef1826a7fa44cc01d8b2a.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-Id: <20241221225804.96AA91121508@dd30410.kasserver.com> Date: Sat, 21 Dec 2024 23:58:04 +0100 (CET) X-Spamd-Bar: + X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 0CA2C103C X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -3.20 X-Spam-Score: -3.20 X-TUID: aGibdjPLa6NE Hi Liliana > I don't think referring to a manifest as necessarily "manifest.scm" > helps us here. It's the one that guix shell and emacs-buffer-env pick up by default. > If you only have one "guix.scm" and one "manifest.scm" > at most, then yes, whatever you need for your hacking setup to work > will have to bleed into the latter. But it wouldn't be too weird > putting emacs, emacs-snail, julia, julia-cstparser and julia-tokenize > into one "snail-manifest.scm", that you can reuse for multiple > projects. Tomorrow, emacs-julia-snail could drop cstparser for xyzparser. And "snail-manifest.scm" is not what buffer-env uses. We'd have to patch buffer-env so it tries 10 different names in priority order or something. Or every programmer would have to manually set up init.el to do: (setq buffer-env-script-name '("julia-snail-manifest.scm" "python-lsp-manifest.scm" "python-repl-manifest.scm" "c-manifest.scm" ... "xyz-manifest.scm" "manifest.scm" ".envrc")) I think that's a cop out. Instead of fixing it, make the user fiddle with it manually. It's the unix way. Let's not do that if possible. > If you want to look at a comparable situation, look at emacs-geiser and > its implementations like emacs-geiser-guile. Here, the reference to > guile in geiser is patched to point at the correct guile – load paths > pose no issue. I had a look at it now. Not sure it's the same situation. Is it? I think in the guile situation it's not that bad because parsing guile is not exactly difficult enough to need a library (or two :) ). In the case of julia the situation is: emacs-julia-snail launches the executable "julia" and uses julia's "cstparser" and "tokenize"--both of which are non-standard julia modules--to figure out what of the communication buffer to use. (It has to do that because the julia grammar is complicated) Note: The julia REPL SHOULD load any other user modules from the guix environment of the manifest! That is, the current guix environment is the correct environment for the REPL for almost every module (except two--and even those maybe it should pick up in all non-automatic-emacs situations). ----------------- In my earlier attempts using julia-snail on guix master was even worse: If "julia" is not in the manifest but "julia-cstparser" is in the manifest, then the search path for julia modules will not be set up and consequently cstparser will not be found. That is the case even if "julia" would be in the guix profile anyway (!!). I fixed it by installing "don't do that then" into my head. But my goal is not fixing it just for myself (I did work around this stuff already) but to make the experience of guix users better. Do you agree that this specific situation is terrible? I mean I know why it is like that technically--but it's still bad. Can't we have nested guix environments somehow pick up search paths even in that situation? Or warn about the situation? Anything but what it does currently. ----------------- > If we can do something similar for julia, that'd be > great, but… I think leaking cstparser might be a no-no, would it? What do you mean, exactly? If you mean this: If the user has to explicitly specify the word "cstparser" it will become an official interface and will break if emacs-julia-snail ever uses xyzparser instead of cstparser in the future. Therefore, emacs-julia-snail must not switch those out in the next 10 years or so. I mean we can do that but in my opinion it's not the best solution. If you mean that: The only problem with bundling cstparser is that you can't load another cstparser as the end user in the same (snail) repl. You will just get the first one if you try. That's it. Maybe there's even something like (@ (cstparser) x) that wouldn't even keep the module loaded. If so, would also be a possibility to use that. Would it be so bad? For me, it's important that guix doesn't silently do nothing when I put another cstparser in the same environment. I have no problem even with an error message and failure that says that there's already a cstparser and why am I trying to add another cstparser. For that matter, we could rename the emacs julia cstparser module to some random string and use it like that. That's ... actually my favorite solution now! It's all nice and good to have all those possibilities but which one do we take, or at least recommend? The situation in guix master surely is not acceptable--see my older mail where I described just how bad it is in vivid detail. > I mean, you could start pure guix shells as emacs subprocesses. Good idea! This is an excellent observation and I can think of multiple other bad guix situations (end user programs pick the wrong gtk up etc) that can (and probably should) be fixed like that for everyone! (For using a supposedly purely functional package manager I'm using a surprising amount of my lifetime to prevent environmental leakage from breaking my stuff. I *should* do "guix shell --pure" right after login so the gdm env var leakage into my desktop session is gone, for example) For building projects I use guix build -f guix.scm (yes, from within emacs) and those are isolated anyway. So I guess if emacs did some extra weird stuff when the user is not building the project yet it would not be that bad anyway.