GNU logs - #72994, boring messages

Message sent to andrew@HIDDEN, cox.katherine.e+guix@HIDDEN, liliana.prikler@HIDDEN, guix-patches@HIDDEN:

Subject: [bug#72994] [PATCH] gnu: emacs-julia-snail: Vendor julia libraries.
Resent-From: Danny Milosavljevic <dannym@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: andrew@HIDDEN, cox.katherine.e+guix@HIDDEN, liliana.prikler@HIDDEN, guix-patches@HIDDEN
Resent-Date: Tue, 03 Sep 2024 04:34:02 +0000
Resent-Message-ID: <handler.72994.B.172533801014734 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 72994 <at> debbugs.gnu.org
Cc: Danny Milosavljevic <dannym@HIDDEN>, Andrew Tropin <andrew@HIDDEN>, Katherine Cox-Buday <cox.katherine.e+guix@HIDDEN>, Liliana Marie Prikler <liliana.prikler@HIDDEN>
From: Danny Milosavljevic <dannym@HIDDEN>
Date: Tue,  3 Sep 2024 02:02:18 +0200
Message-ID: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=23.83.209.27;
 envelope-from=dannym@HIDDEN;
 helo=butterfly.birch.relay.mailchannels.net
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,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Mailman-Approved-At: Tue, 03 Sep 2024 00:33:27 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)

* gnu/packages/patches/emacs-julia-snail-1.3.1-vendor.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/emacs-xyz.scm (emacs-julia-snail)[arguments]<#:phases>[vendor]:
New phase.
[inputs]: Add julia-cstparser, julia-tokenize.
[propagated-inputs]: Remove julia-cstparser, julia-tokenize.
[source]: Add patch.

Change-Id: I61c0a4493fcfd219809bcc35f8765be0928a7e81
---
 gnu/local.mk                                  |  1 +
 gnu/packages/emacs-xyz.scm                    | 25 ++++++--
 .../emacs-julia-snail-1.3.1-vendor.patch      | 57 +++++++++++++++++++
 3 files changed, 78 insertions(+), 5 deletions(-)
 create mode 100644 gnu/packages/patches/emacs-julia-snail-1.3.1-vendor.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 0c4ab96bf3..8647956f2f 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1179,6 +1179,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/emacs-git-email-missing-parens.patch	\
   %D%/packages/patches/emacs-helpful-fix-tests.patch	\
   %D%/packages/patches/emacs-highlight-stages-add-gexp.patch	\
+  %D%/packages/patches/emacs-julia-snail-1.3.1-vendor.patch	\
   %D%/packages/patches/emacs-json-reformat-fix-tests.patch	\
   %D%/packages/patches/emacs-kv-fix-tests.patch	\
   %D%/packages/patches/emacs-lispy-fix-thread-last-test.patch   \
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 370daaf50e..1837c759d2 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -14656,22 +14656,37 @@ (define-public emacs-julia-snail
               (file-name (git-file-name name version))
               (sha256
                (base32
-                "0h5lwc2hsk4rc82idhf9qj9553v7x76wmy9x2z1h60pdd93ilcyr"))))
+                "0h5lwc2hsk4rc82idhf9qj9553v7x76wmy9x2z1h60pdd93ilcyr"))
+              (patches
+               (search-patches "emacs-julia-snail-1.3.1-vendor.patch"))))
     (build-system emacs-build-system)
     (arguments
      (list
+      #:phases
+      #~(modify-phases %standard-phases
+          (add-after 'validate-compiled-autoloads 'vendor
+            (lambda* (#:key inputs outputs #:allow-other-keys)
+              (let* ((out (assoc-ref outputs "out"))
+                     (base (dirname (car (find-files out "JuliaSnail.jl"))))
+                     (vendor (string-append base "/vendor")))
+                (mkdir-p vendor)
+                (copy-recursively (string-append (assoc-ref inputs "julia-cstparser")
+                                                 "/share/julia/loadpath/CSTParser")
+                                  (string-append vendor "/CSTParser"))
+                (copy-recursively (string-append (assoc-ref inputs "julia-tokenize")
+                                                 "/share/julia/loadpath/Tokenize")
+                                  (string-append vendor "/Tokenize"))))))
       #:include
       #~(cons* "^JuliaSnail\\.jl" "extensions" %default-include)))
     (inputs
-     (list emacs-dash emacs-s emacs-spinner emacs-xref))
+     (list emacs-dash emacs-s emacs-spinner emacs-xref julia-cstparser
+           julia-tokenize))
     (propagated-inputs
      (list libvterm
            emacs-julia-mode             ;required by parser
            emacs-parsec                 ;required by parser
            emacs-popup
-           emacs-vterm
-           julia-tokenize
-           julia-cstparser))
+           emacs-vterm))
     (home-page "https://github.com/gcv/julia-snail")
     (synopsis "Development environment and REPL interaction package for Julia")
     (description "This package provides a development environment and REPL
diff --git a/gnu/packages/patches/emacs-julia-snail-1.3.1-vendor.patch b/gnu/packages/patches/emacs-julia-snail-1.3.1-vendor.patch
new file mode 100644
index 0000000000..eaa38fb868
--- /dev/null
+++ b/gnu/packages/patches/emacs-julia-snail-1.3.1-vendor.patch
@@ -0,0 +1,57 @@
+Author: Danny Milosavljevic <dannym@HIDDEN>
+Date: 2024-09-03
+License: GPL3+
+
+Previously, we propagated julia-cstparser and julia-tokenize. This would only
+work if the user had installed julia in their profile (because only then
+JULIA_LOAD_PATH of julia-cstparser would be propagated).
+That doesn't seem likely or desireable.
+
+It turns out that it's not difficult to make julia read vendored packages.
+Let's do that (since there's a comment inside JuliaSnail.jl that warns about
+CSTParser APIs being easily incompatible, vendoring is better anyway).
+
+diff -ru orig/4l8xr3ldffb30a44x157lj3asaj3ykls-emacs-julia-snail-1.3.1-checkout/JuliaSnail.jl 4l8xr3ldffb30a44x157lj3asaj3ykls-emacs-julia-snail-1.3.1-checkout/JuliaSnail.jl
+--- orig/4l8xr3ldffb30a44x157lj3asaj3ykls-emacs-julia-snail-1.3.1-checkout/JuliaSnail.jl	2024-09-03 00:02:03.798373662 +0200
++++ 4l8xr3ldffb30a44x157lj3asaj3ykls-emacs-julia-snail-1.3.1-checkout/JuliaSnail.jl	2024-09-03 01:05:26.310766009 +0200
+@@ -30,12 +30,12 @@
+    catch err
+       if isa(err, ArgumentError)
+          if isfile(joinpath($dir, "Project.toml"))
+-            # force dependency installation
+-            Main.Pkg.activate($dir)
+-            Main.Pkg.instantiate()
+-            Main.Pkg.precompile()
+-            # activate what was the first entry before Snail was pushed to the head of LOAD_PATH
+-            Main.Pkg.activate(LOAD_PATH[2])
++             # force dependency installation
++             if isa(err, ArgumentError)
++                 error("Vendored dependencies not found. Please make sure the vendored packages are located in the 'vendor' directory.")
++             else
++                 rethrow(err)
++             end
+          end
+       end
+    finally
+@@ -51,11 +51,16 @@
+ end
+ 
+ @with_pkg_env (@__DIR__) begin
+-   # list all external dependency imports here (from the appropriate Project.toml, either Snail's or an extension's):
+-   import CSTParser
+-   # check for dependency API compatibility
+-   !isdefined(CSTParser, :iscall) &&
+-     throw(ArgumentError("CSTParser API not compatible, must install Snail-specific version"))
++    @with_pkg_env (joinpath(@__DIR__, "vendor", "CSTParser")) begin
++        @with_pkg_env (joinpath(@__DIR__, "vendor", "Tokenize")) begin
++            println(LOAD_PATH)
++            # list all external dependency imports here (from the appropriate Project.toml, either Snail's or an extension's):
++            import CSTParser
++            # check for dependency API compatibility
++            !isdefined(CSTParser, :iscall) &&
++                throw(ArgumentError("CSTParser API not compatible, must install Snail-specific version"))
++        end
++    end
+ end
+ 
+ 

base-commit: b833aaaee7c95ec0339428a6b602f26831494798
-- 
2.45.2

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Danny Milosavljevic <dannym@HIDDEN>
Subject: bug#72994: Acknowledgement ([PATCH] gnu: emacs-julia-snail:
 Vendor julia libraries.)
Message-ID: <handler.72994.B.172533801014734.ack <at> debbugs.gnu.org>
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
X-Gnu-PR-Message: ack 72994
X-Gnu-PR-Package: guix-patches
X-Gnu-PR-Keywords: patch
Reply-To: 72994 <at> debbugs.gnu.org
Date: Tue, 03 Sep 2024 04:34:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  Andrew Tropin <andrew@HIDDEN>, Katherine Cox-Buday <cox.katherine.e+guix=
@gmail.com>, Liliana Marie Prikler <liliana.prikler@HIDDEN>
(after having been given a bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 guix-patches@HIDDEN

If you wish to submit further information on this problem, please
send it to 72994 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
72994: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72994
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to guix-patches@HIDDEN:

Subject: [bug#72994] [PATCH] gnu: emacs-julia-snail: Vendor julia libraries.
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 16 Sep 2024 08:25:01 +0000
Resent-Message-ID: <handler.72994.B72994.172647507031846 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Danny Milosavljevic <dannym@HIDDEN>
Cc: Katherine Cox-Buday <cox.katherine.e+guix@HIDDEN>, 72994 <at> debbugs.gnu.org, Liliana Marie Prikler <liliana.prikler@HIDDEN>, Andrew Tropin <andrew@HIDDEN>
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
 (Danny Milosavljevic's message of "Tue, 3 Sep 2024 02:02:18 +0200")
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
Date: Mon, 16 Sep 2024 10:24:04 +0200
Message-ID: <87cyl49fbv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hey Danny,

Danny Milosavljevic <dannym@HIDDEN> skribis:

> * gnu/packages/patches/emacs-julia-snail-1.3.1-vendor.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/emacs-xyz.scm (emacs-julia-snail)[arguments]<#:phases>[ven=
dor]:
> New phase.
> [inputs]: Add julia-cstparser, julia-tokenize.
> [propagated-inputs]: Remove julia-cstparser, julia-tokenize.
> [source]: Add patch.
>
> Change-Id: I61c0a4493fcfd219809bcc35f8765be0928a7e81

[...]

> +          (add-after 'validate-compiled-autoloads 'vendor
> +            (lambda* (#:key inputs outputs #:allow-other-keys)
> +              (let* ((out (assoc-ref outputs "out"))
> +                     (base (dirname (car (find-files out "JuliaSnail.jl"=
))))
> +                     (vendor (string-append base "/vendor")))
> +                (mkdir-p vendor)
> +                (copy-recursively (string-append (assoc-ref inputs "juli=
a-cstparser")
> +                                                 "/share/julia/loadpath/=
CSTParser")
> +                                  (string-append vendor "/CSTParser"))
> +                (copy-recursively (string-append (assoc-ref inputs "juli=
a-tokenize")
> +                                                 "/share/julia/loadpath/=
Tokenize")

Use =E2=80=98search-input-directory=E2=80=99 rather than =E2=80=98assoc-ref=
=E2=80=99.

> +++ b/gnu/packages/patches/emacs-julia-snail-1.3.1-vendor.patch
> @@ -0,0 +1,57 @@
> +Author: Danny Milosavljevic <dannym@HIDDEN>
> +Date: 2024-09-03
> +License: GPL3+
> +
> +Previously, we propagated julia-cstparser and julia-tokenize. This would=
 only
> +work if the user had installed julia in their profile (because only then
> +JULIA_LOAD_PATH of julia-cstparser would be propagated).
> +That doesn't seem likely or desireable.
> +
> +It turns out that it's not difficult to make julia read vendored package=
s.
> +Let's do that (since there's a comment inside JuliaSnail.jl that warns a=
bout
> +CSTParser APIs being easily incompatible, vendoring is better anyway).

I=E2=80=99m not sure I understand.  For most programming languages (Python,
etc.), we use propagated inputs like this.  How does that differ?

Normally we unbundle (=E2=80=9Cunvendor=E2=80=9D?) libraries and this seems=
 to go in the
opposite direction, right?

Thanks,
Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

Subject: [bug#72994] [PATCH] gnu: emacs-julia-snail: Vendor julia libraries.
Resent-From: dannym@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 16 Sep 2024 18:02:02 +0000
Resent-Message-ID: <handler.72994.B72994.172650970326914 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Katherine Cox-Buday <cox.katherine.e+guix@HIDDEN>, 72994 <at> debbugs.gnu.org, Liliana Marie Prikler <liliana.prikler@HIDDEN>, Andrew Tropin <andrew@HIDDEN>
MIME-Version: 1.0
Date: Mon, 16 Sep 2024 20:01:16 +0200
From: dannym@HIDDEN
In-Reply-To: <87cyl49fbv.fsf@HIDDEN>
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
 <87cyl49fbv.fsf@HIDDEN>
User-Agent: Roundcube Webmail/1.5.0
Message-ID: <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi Ludo,

On 2024-09-16 10:24, Ludovic Courtès wrote:
>> +                (copy-recursively (string-append (assoc-ref inputs 
>> "julia-tokenize")
>> +                                                 
>> "/share/julia/loadpath/Tokenize")
> 
> Use ‘search-input-directory’ rather than ‘assoc-ref’.

Will do!

> I’m not sure I understand.  For most programming languages (Python,
> etc.), we use propagated inputs like this.  How does that differ?
> 
> Normally we unbundle (“unvendor”?) libraries and this seems to go in 
> the
> opposite direction, right?

The idea is to make Guix more user-friendly.

I touched this only after I myself got bitten by the following:

I have guix home (with only a few packages--notably no julia (!) or 
gcc-toolchain
or anything like that in it),
and I have emacs set up with emacs-buffer-env and the following 
configuration:

   (setq buffer-env-script-name '("manifest.scm" ".envrc"))

In a julia project, manifest.scm contains:

   (specifications->manifest
     (list "julia"))

The idea is that emacs-bufferenv will automatically load that manifest 
when I
open a file in that directory within emacs--and then have julia-snail 
REPL
(including sending expression on point to the REPL) work.

Since the emacs julia-snail REPL integration needs to find the bounds of 
the expression,
it has to have a parser for the Julia language.

However, what happens now is that because I don't have julia-cstparser 
and julia-tokenize
in guix home, it won't work.

But from the standpoint of the profile I shouldn't have julia-cstparser 
and julia-tokenize
in my home profile since I don't personally directly use it (it's a 
requirement of emacs-julia-snail--I didn't even know what 
julia-cstparser is a few days ago :) ).

But nevermind that.  Even if I added julia-cstparser and julia-tokenize 
to my
guix home profile, it would NOT work.  The reason is because julia 
itself is not part of
the guix home profile, and the "julia" package would have a search-path 
specification that
would set some environment variables that julia needs to find 
julia-cstparser and
julia-tokenize.
Since the package is not there (in guix home) it won't set the 
variables.

The idea of this patch is that emacs will automatically set up whatever 
it needs to in order
to make the REPL work (including the finding of the boundaries of the 
current expression
that the emacs package needs for "send expression at point to REPL") 
without weird
dependencies bleeding explicitly into the user profile or into the local 
directory's manifest.

In my opinion, the user should not need to be concerned with what 
julia-cstparser is in this case.

Emacs should just magically load whatever it needs for the Julia REPL to 
work (whether
that's written in Julia or Python or whatever is an implementation 
detail--you COULD
have a Julia parser written in Python. Notably, most parsers for any 
language in
IntelliJ IDEA are written in Java--the Python parser, Rust parser etc).

That said, I'm totally open to other ways to do it.

The obvious alternative would be for the user to put julia-cstparser and 
julia-tokenize
into every Julia project's manifest.scm . But the error message is 
inscrutable if you
don't have those in there[1]--and I have no idea how any normal person 
would figure out
that julia-cstparser is needed in the first place.

[1] julia-snail--send-to-server: No Julia REPL buffer *julia* found; run 
julia-snail
Starting Julia process and loading Snail...
julia-snail--repl-enable: The REPL terminal buffer is inactive; 
double-check julia-snail-executable path

(In buffer "*scratch*" : )
julia-snail-executable
"julia"

(note: that "julia" excutable IS available in the manifest of the buffer 
env--and launching "julia" does work when launched manually within 
emacs)

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#72994] [PATCH] gnu: emacs-julia-snail: Vendor julia libraries.
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 17 Sep 2024 17:21:02 +0000
Resent-Message-ID: <handler.72994.B72994.17265936304030 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72994
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: dannym@HIDDEN, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: Katherine Cox-Buday <cox.katherine.e+guix@HIDDEN>, 72994 <at> debbugs.gnu.org, Andrew Tropin <andrew@HIDDEN>
Received: via spool by 72994-submit <at> debbugs.gnu.org id=B72994.17265936304030
          (code B ref 72994); Tue, 17 Sep 2024 17:21:02 +0000
Received: (at 72994) by debbugs.gnu.org; 17 Sep 2024 17:20:30 +0000
Received: from localhost ([127.0.0.1]:55855 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sqbsM-00012w-0C
	for submit <at> debbugs.gnu.org; Tue, 17 Sep 2024 13:20:30 -0400
Received: from mail-wr1-f68.google.com ([209.85.221.68]:52531)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1sqbsK-0000zA-4H
 for 72994 <at> debbugs.gnu.org; Tue, 17 Sep 2024 13:20:29 -0400
Received: by mail-wr1-f68.google.com with SMTP id
 ffacd0b85a97d-378c16a4d3eso4758114f8f.1
 for <72994 <at> debbugs.gnu.org>; Tue, 17 Sep 2024 10:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1726593547; x=1727198347; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=p90+TOPTy+0L+swv/U0nS0eZCM7TZlydWgPQZhGBU1M=;
 b=T7clUP2+zb6d1viUx9Qz41SnWF96t83Nr5wk1C4YJ+PNAQh6PqkKjaDr66vDu5dKOm
 3ydkmC1ypWEOhCDdT8YFNvFh0oQ14yoAoVnA1Hhv0K2dy69g/Z5mvgEsJ3bG3UjSKGut
 iNGlcVlOiJ/vxuLzMhQg/YDDQ4uWmY/6/vFlPF291dhXnIq0pmltVIfl9dvaYbK6EOPc
 gSBEODEeQ2rAGJMVcZg6yCbJAPyoZ4TQ/DUFTA4eSapjX6XhTWPH/F7Lfh0TFnVT7ylB
 km7xH+X3R8cDCt6uMomBJ8DUYxgggl3defuGEEBq9lfjoD9kHkJAHRvYOlEcuRPnU09A
 hzmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1726593547; x=1727198347;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=p90+TOPTy+0L+swv/U0nS0eZCM7TZlydWgPQZhGBU1M=;
 b=SgzxxmFpMnHNw/V0m7oMZ57BzcT76q23X0dX/YMhhf2G6D/YRaIMrStIWZQzyUzGmB
 u6S5rfVJ2ZXlHPfb16R3np0SLqgnbaO6s+vJEb1VqeQfaKcce+y8PGUnAzR1+TIR3c8h
 Lhnryp8+ShwTi6R09pgBS/9leBKgM1uhD0/jKFbDSCF/8Q8LP+zxoQeW1pdo1ls5mUdQ
 SXEazHd6by3WO4AFn98BwpLjlGFYfHpz7M6S8DccR8KoM00n5sUgg2dyYefkjZws/URd
 YRuPgbE6GiSnEdLSwuIE3uR7V8cPtfMDq9GS+nhg23lkf41funLxJeQSr8fRR7m2te1D
 GVWw==
X-Gm-Message-State: AOJu0YyP8Tp7uBHLcJB5fd6w34HyXfRIPuuIHl7DyHdFsnBzaLiFs2bt
 UtOPvB1WAjI5PBgYuJdaXMr0/NHvok5ith/qTjYpLj5cVT/iaInB
X-Google-Smtp-Source: AGHT+IGfZLDjewBnxYvLbj3WCwMptwxnVAHglrp4eldRVc54v4up4z68rYUU6oWdsFtyyMKTusVYGQ==
X-Received: by 2002:adf:f111:0:b0:374:bb28:2c29 with SMTP id
 ffacd0b85a97d-378d61712bcmr13196760f8f.0.1726593546938; 
 Tue, 17 Sep 2024 10:19:06 -0700 (PDT)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-378e7800243sm10079832f8f.86.2024.09.17.10.19.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 17 Sep 2024 10:19:06 -0700 (PDT)
Message-ID: <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Tue, 17 Sep 2024 19:19:04 +0200
In-Reply-To: <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
 <87cyl49fbv.fsf@HIDDEN>
 <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Danny,

Am Montag, dem 16.09.2024 um 20:01 +0200 schrieb
dannym@HIDDEN:
> The idea of this patch is that emacs will automatically set up
> whatever it needs to in order to make the REPL work (including the
> finding of the boundaries of the current expression that the emacs
> package needs for "send expression at point to REPL")  without weird
> dependencies bleeding explicitly into the user profile or into the
> local directory's manifest.
You could write a meta package =C3=A0 la "julia stuff for emacs-julia-snail=
"
and mention that in the description, no?  I think bundling (or
propagating) these dependencies from the package is likely not going to
do us favours in weird edge cases where you actually want more julia
packages, e.g. in the julia package that you may or may not be hacking
on, which has other dependencies :)

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#72994] [PATCH] gnu: emacs-julia-snail: Vendor julia libraries.
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 17 Oct 2024 07:44:02 +0000
Resent-Message-ID: <handler.72994.B72994.17291509983079 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72994
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Cc: Katherine Cox-Buday <cox.katherine.e+guix@HIDDEN>, 72994 <at> debbugs.gnu.org, dannym@HIDDEN, Andrew Tropin <andrew@HIDDEN>
Received: via spool by 72994-submit <at> debbugs.gnu.org id=B72994.17291509983079
          (code B ref 72994); Thu, 17 Oct 2024 07:44:02 +0000
Received: (at 72994) by debbugs.gnu.org; 17 Oct 2024 07:43:18 +0000
Received: from localhost ([127.0.0.1]:33251 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1t1LAE-0000nb-3Q
	for submit <at> debbugs.gnu.org; Thu, 17 Oct 2024 03:43:18 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43830)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1t1LAB-0000nM-HS
 for 72994 <at> debbugs.gnu.org; Thu, 17 Oct 2024 03:43:16 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1t1L9l-00025h-5G; Thu, 17 Oct 2024 03:42:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=zq9xyQAcm2YORedg6rXuNsFPTWtx7bGfwNZakgBtGeo=; b=eW8Z5qbtdlUJ4e/nWo7c
 ttlB69/vkSVAzvytTZvTJ8sZBDB97oL+7FZGx/C+ZfyWCKc9VRjSBodObg0w3AkPHNKFmgKb5nqne
 8JVB4rkLazfXCTS/WcDLEs9bgU+CCh4gdSBVrV3zgs4mvPOK9r1LYunsI3W5Y6oh4QVWBtJaNo4D4
 5Z6LRODUZcVE6O2KQrVJNqWfPMQ6uZoI626Gl5C0qgUjmgE0k0+o5KcVDOrBx0sxrTw8JIh6NVb1D
 FBasH1cjQ15i6FbkzJQwqRQzjA2sZqAnDr8BMvWA1i2XwwZXwQTV4Ui9+pOWDQMbDu+tP0m8DcSuO
 fVYIArPujKYV5g==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@HIDDEN>
 (Liliana Marie Prikler's message of "Tue, 17 Sep 2024 19:19:04 +0200")
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
 <87cyl49fbv.fsf@HIDDEN>
 <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
 <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@HIDDEN>
Date: Thu, 17 Oct 2024 09:42:45 +0200
Message-ID: <87zfn3rx8q.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi Danny & Liliana,

Liliana Marie Prikler <liliana.prikler@HIDDEN> skribis:

> Am Montag, dem 16.09.2024 um 20:01 +0200 schrieb
> dannym@HIDDEN:
>> The idea of this patch is that emacs will automatically set up
>> whatever it needs to in order to make the REPL work (including the
>> finding of the boundaries of the current expression that the emacs
>> package needs for "send expression at point to REPL")  without weird
>> dependencies bleeding explicitly into the user profile or into the
>> local directory's manifest.

Thanks for explaining!

> You could write a meta package =C3=A0 la "julia stuff for emacs-julia-sna=
il"
> and mention that in the description, no?

Yes, sounds like a good idea to me.  WDYT, Danny?

Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#72994] manifest.scm and emacs-specific things
Resent-From: "Danny Milosavljevic" <dannym@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 21 Dec 2024 18:34:01 +0000
Resent-Message-ID: <handler.72994.B72994.17348060214050 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72994
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: liliana.prikler@HIDDEN, ludo@HIDDEN
Cc: cox.katherine.e+guix@HIDDEN, 72994 <at> debbugs.gnu.org, dannym@HIDDEN, andrew@HIDDEN
Received: via spool by 72994-submit <at> debbugs.gnu.org id=B72994.17348060214050
          (code B ref 72994); Sat, 21 Dec 2024 18:34:01 +0000
Received: (at 72994) by debbugs.gnu.org; 21 Dec 2024 18:33:41 +0000
Received: from localhost ([127.0.0.1]:47675 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tP4IG-00013G-NO
	for submit <at> debbugs.gnu.org; Sat, 21 Dec 2024 13:33:41 -0500
Received: from dd30410.kasserver.com ([85.13.145.193]:58982)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dannym@HIDDEN>) id 1tP4ID-000136-K8
 for 72994 <at> debbugs.gnu.org; Sat, 21 Dec 2024 13:33:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scratchpost.org;
 s=kas202409041115; t=1734806015;
 bh=S9NE5iilN4sw/ijZM0FG6Dyj1VVNuiDegbz1ujMFt+Y=;
 h=Subject:To:References:Cc:From:In-Reply-To:Date:From;
 b=nyjO7Q3M/5yfcoc2FSZG/cC+DDls0UjLPCLec3sHWFGmharESDfa3RHS1Tr4pXpIl
 4uxnhsZnfPEJQJvc331ne06cu4QSKEZ7CUiFjDlxjyj6fgz7jmlJxW9arzlszR5929
 0SFkzUOpX/dZKTdypiPjMaGNDBzQVKA6f1rJIWLmD7Wom+qvWlgqNGR/YCs+jU4Z96
 gQb/cXgWIxLYw0nwUhHJRNHXor1rNvgAkIjKbN0DXr6GuW6gjuXYTuTVpUZk1Rs0fq
 JVxE/T505m79skw6E9a1BOKvctAAf+XOgm7RCbZuq1MsbE/x37j08uypkWboffc4Dp
 kMdjP0Ar8oXWw==
Received: from dd30410.kasserver.com (dd0802.kasserver.com [85.13.143.1])
 by dd30410.kasserver.com (Postfix) with ESMTPSA id 2740D1120E20;
 Sat, 21 Dec 2024 19:33:35 +0100 (CET)
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
 <87cyl49fbv.fsf@HIDDEN>
 <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
 <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@HIDDEN>
 <87zfn3rx8q.fsf@HIDDEN>
From: "Danny Milosavljevic" <dannym@HIDDEN>
User-Agent: ALL-INKL Webmail 2.11
X-SenderIP: 213.147.164.14
MIME-Version: 1.0
In-Reply-To: <87zfn3rx8q.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-Id: <20241221183335.2740D1120E20@HIDDEN>
Date: Sat, 21 Dec 2024 19:33:35 +0100 (CET)
X-Spamd-Bar: +
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi!

> > On Mon, 16 Sep 2024 20:01 +0200 
> > dannym@HIDDEN wrote:
> >> The idea of this patch is that emacs will automatically set up
> >> whatever it needs to in order to make the REPL work (including the
> >> finding of the boundaries of the current expression that the emacs
> >> package needs for "send expression at point to REPL") without weird
> >> dependencies bleeding explicitly into the user profile or into the
> >> local directory's manifest.
> 
> Thanks for explaining!
> 
> > You could write a meta package à la "julia stuff for emacs-julia-snail"
> > and mention that in the description, no?
> 
> Yes, sounds like a good idea to me. WDYT, Danny?

I'm not yet sure.

I can of course add a "julia-toolchain" or something but it's really NOT
a julia toolchain thing. It's a local emacs-julia-snail thing that emacs
punted to some other language (as emacs is wont to do--delegate
things to other processes/languages/...).

A lot of dynamic languages do something like this in emacs and will
run into similar problems. Whatever the official way to do, we should
decide what to do and document it.

(I do think it's a good design to ask the actual Julia REPL about things
instead of reimplementing a Julia parser in elisp. That way it stays
current with reality)

The propagated inputs I would have added is so it WOULD conflict and
fail if you tried to add another Julia parser library (fail guix shell
on purpose!).

That's because, like most dynamic languages, you really can't load
two different modules that are named the same into the same
runtime without doing unholy things first. Otherwise, it would just
not do anything and use the existing one--which is probably not
what you wanted.

For the odd case when you are hacking on cstparser itself, you can
always not use the REPL and not use buffer-env. As you saw before,
julia-cstparser and julia-tokenize are currently NOT optional in
emacs anyway--the REPL won't start without--and with a totally
inscrutable error message that tries to make it julia's fault (it isn't).

So what I'm envisioning is documenting emacs-buffer-env like that:

(define-public emacs-buffer-env
  (package
    ...
    (description "In emacs, emacs-buffer-env can pick up manifest.scm from a
project directory automatically.

The contents of manifest.scm should be as follows:
(specifications->manifest (list

...
@item for Julia, it is recommended to add "julia-emacs-toolchain"
...
))
")))
Or something?

Because the following would leak emacs implementation details (arguably in a lot of cases!):

    (description "In emacs, emacs-buffer-env can pick up manifest.scm from a
project directory automatically.

The contents of manifest.scm should be as follows:
(specifications->manifest (list

@item for C and C++, it is recommended to add "gcc-toolchain" "binutils" "ccls" "bear"
@item for Python, it is recommended to add "python" "python-debugpy" "python-lsp-server"
@item for LaTeX, it is recommended to add "texlive-minted" "texlive-latex-bin" "dvisvgm"
@item for Prolog, it is recommended to add "swi-prolog" "emacs-ediprolog"
@item for Julia, it is recommended to add "julia" "julia-cstparser" "julia-tokenize"
@item for Vala, it is recommended to add "vala" "gcc-toolchain" "binutils" "vala-language-server" "gobject-introspection" "pkg-config"
        "meson" "ninja"
        ;; Note: That's the wrong glib
        "glib"
        ;; Note: That's the wrong gtk+
        "gtk+"
@item for Go, it is recommended to add "go"
@item for Rust, it is recommended to add "rust" "rust:cargo" "gcc-toolchain"
@item for R, it is recommended to add "r"
@item for Rust, it is recommendeed to add "ruby"
@item for Haskell, it is recommended to add "ghc" "gcc-toolchain"
@item for Java, it is recommended to add "openjdk" "openjdk:jdk"
@item for Zig, it is recommended to add "zig" "zig-zls"
@item for Perl, it is recommended to add "perl"
@item for SBCL, it is recommended to add "sbcl"
@item for Node, it is recommended to add "node"
@item for FPC, it is recommended to add "fpc"
@item for Ocaml, it is recommended to add "ocaml"
@item for Racket, it is recommended to add "racket"
@item for Chicken, it is recommended to add "chicken"
@item for D, it is recommended to add "dub" "ldc" "gcc-toolchain"
@item for Nim, it is recommended to add "nim"

))
")))

Adding julia-cstparser julia-tokenize inside julia-toolchain would be weird, no?

Also, for example for Python, worse, there's a python LSP server emacs thing, OR
there's a non-LSP emacs thing that asks the Python REPL directly  (!). I actually
prefer the latter because C-M-x works in emacs Python then (but C-M-x doesn't
work with python-debugpy and python-lsp-server in emacs--at least not for me).

I think making a public package "julia-emacs-toolchain" would be less weird.

(define-public julia-emacs-toolchain
  (package
    ...
    (propagated-inputs (list julia julia-cstparser julia-tokenize))))

Like that?

Which variant exactly do we want? Do we want end users to create
"manifest.scm"s like that, i.e. should those "xxx-emacs-toolchain"
package names be part of a Guix stable interface ?

emacs-julia-snail would not propagate julia-emacs-toolchain
then? Or would it?

(Personally, I think in an ideal world, *emacs* would run in its own
guix profile and when you do M-x list-packages in emacs and install
a package it would just install it into its emacs profile using
"guix package"[1]. Somehow, the emacs environment so configured
should not bleed into processes started by the user inside emacs.
But that's a long way off maybe and not sure whether it would be
a good idea.
In any case it should be *almost* independent of this here)

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#72994] manifest.scm and emacs-specific things
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 21 Dec 2024 20:21:03 +0000
Resent-Message-ID: <handler.72994.B72994.173481246123877 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72994
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Danny Milosavljevic <dannym@HIDDEN>, ludo@HIDDEN
Cc: cox.katherine.e+guix@HIDDEN, 72994 <at> debbugs.gnu.org, dannym@HIDDEN, andrew@HIDDEN
Received: via spool by 72994-submit <at> debbugs.gnu.org id=B72994.173481246123877
          (code B ref 72994); Sat, 21 Dec 2024 20:21:03 +0000
Received: (at 72994) by debbugs.gnu.org; 21 Dec 2024 20:21:01 +0000
Received: from localhost ([127.0.0.1]:47794 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tP5y9-0006D3-1T
	for submit <at> debbugs.gnu.org; Sat, 21 Dec 2024 15:21:01 -0500
Received: from mail-wm1-f66.google.com ([209.85.128.66]:49434)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1tP5y6-0006Cp-Nc
 for 72994 <at> debbugs.gnu.org; Sat, 21 Dec 2024 15:20:59 -0500
Received: by mail-wm1-f66.google.com with SMTP id
 5b1f17b1804b1-4361e89b6daso20523355e9.3
 for <72994 <at> debbugs.gnu.org>; Sat, 21 Dec 2024 12:20:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1734812393; x=1735417193; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=Gafh6IQ8ff3wE+5URf16lRMk0PzlRyMXgTdmo1g3q7E=;
 b=kmnli7Sw2eN5/D2mXVi4djn8gSPj5sEFYlPHtLpiKIjAAen7YWAxY3mGwvzz7Cxcbi
 9KTZONKYOf7S54szW8cK3YDd1jcPeAreuj+ltuSkJWTkats2SvplMMUEYdmQp9g+fd+T
 RH2wDALa35pf2tD2cfWgM2W2HXNggdqDeD6gozAE/X/rf/zpes9jGARIEsQJ/0kJ4l9m
 9OOKyZPWhoUfS9kWzN2/4X4m3jclwtT8PJpLwQ7nv8pWGS4BmpsUxEFtA3s3AD4MEu4o
 eAMgGdQVvODHT9Oq7xdPyWfzwA/uS2okn6X/pjQDnjOL1xncJxgeOkMi+KS/jGrieVXf
 NXNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1734812393; x=1735417193;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=Gafh6IQ8ff3wE+5URf16lRMk0PzlRyMXgTdmo1g3q7E=;
 b=W8tn2cejyMTv/nRElHOicyjeTUFQosVJLAichc4J8Hb+L8n2ZNxPBDgPR+dQ9XhvJP
 ytfIzWJiGLN8cL/efJcmriJFYX7ewLjlaqpVohaUHYOAfeWtkISip7QjGAPl0BFw0Pvz
 JnU+6iRc1khPRwUi6gdRS3FboEC8I6odfXnbuo3O6cv1hnxu+eEnb7f/E0DCTpvK7FRi
 HNeAY1y0GAY9RJtAMQbTmQWfEbKpkR4IQQwDI9A/skqy7yvRIcW9QG+ZlX/DlkyL9mjK
 9qSeNuDRzKxMXLaE9C1ZvQZuhdarZuoWxTHyHNEwbHnvC/6soVJI4WDUmGW/uH0H5wrq
 omyg==
X-Forwarded-Encrypted: i=1;
 AJvYcCWzpbk1t1QF5xFduZ6GLt1hEftTY9AbBSWdDpV/wH0IRf1iZNe66336p8r02+D9ZPMP+8kx3Q==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yzr7tmUhSR4onsQa8R1q5PWI/vfqvGxVDWDjHHhMKqWxwFot2HN
 PhXgENmjHVc2LlDqgrYmHNDf89vdeQmVij80l05yi908s65RJl4q
X-Gm-Gg: ASbGncu4IFmT+FahcM8a8ErBADbnhAeifYWdhv35L2Lt7BwaV2avp64wjAjCjkdDszK
 pIRQHRhPoAVafaV5z8BqzppsdkD9It7AkDizxJsm5s2wKgSTxGlk5xNQWBPXaAkFjtTvYlGdz9t
 /iw1GYl/oLDU67z2pqda4ySs87aRDFHPgTOlLUzLbfEl8Fdgh204uKXZ8kihiHa7lHnrfzhdBUZ
 MiedKQJaGk3bcgMI+3k3Ps6hl6Iy4OJsUIdmnEiBp3qQyhy/2fLm/cR9/4sIh9TWYHTbOBnmsrM
 Qbuyw7iYDkoG734hKTB5irp9msacIBHa
X-Google-Smtp-Source: AGHT+IH9Ym+dpIiJF1T2uPg4DJY2yMJOc4sptBhmSPaNSqTVz7mwCYi0PlDC6yFTjLw/SkV7Ab/wqw==
X-Received: by 2002:a05:600c:35c9:b0:434:f1e9:afb3 with SMTP id
 5b1f17b1804b1-43668548499mr67214765e9.3.1734812392544; 
 Sat, 21 Dec 2024 12:19:52 -0800 (PST)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4364b14f241sm127965965e9.1.2024.12.21.12.19.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Dec 2024 12:19:52 -0800 (PST)
Message-ID: <6913205399a12a20587ef1826a7fa44cc01d8b2a.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Sat, 21 Dec 2024 21:20:51 +0100
In-Reply-To: <20241221183335.2740D1120E20@HIDDEN>
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
 <87cyl49fbv.fsf@HIDDEN>
 <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
 <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@HIDDEN>
 <87zfn3rx8q.fsf@HIDDEN>
 <20241221183335.2740D1120E20@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi,

Am Samstag, dem 21.12.2024 um 19:33 +0100 schrieb Danny Milosavljevic:
> I think making a public package "julia-emacs-toolchain" would be less
> weird.
>=20
> (define-public julia-emacs-toolchain
> =C2=A0 (package
> =C2=A0=C2=A0=C2=A0 ...
> =C2=A0=C2=A0=C2=A0 (propagated-inputs (list julia julia-cstparser julia-t=
okenize))))
>=20
> Like that?
>=20
> Which variant exactly do we want? Do we want end users to create
> "manifest.scm"s like that, i.e. should those "xxx-emacs-toolchain"
> package names be part of a Guix stable interface ?
>=20
> emacs-julia-snail would not propagate julia-emacs-toolchain
> then? Or would it?
Weird naming choice aside (commented upon below), I don't think it
would even be an input to emacs-julia-snail, much less a propagated
one.  The package, if we need one at all, would need to be public so
that users can actually use it.

I don't think referring to a manifest as necessarily "manifest.scm"
helps us here.  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.

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 =E2=80=93 load pat=
hs
pose no issue.  If we can do something similar for julia, that'd be
great, but=E2=80=A6 I think leaking cstparser might be a no-no, would it?

> (Personally, I think in an ideal world, *emacs* would run in its own
> guix profile and when you do M-x list-packages in emacs and install
> a package it would just install it into its emacs profile using
> "guix package"[1]. Somehow, the emacs environment so configured
> should not bleed into processes started by the user inside emacs.
> But that's a long way off maybe and not sure whether it would be
> a good idea.  In any case it should be *almost* independent of this
> here)
I mean, you could start pure guix shells as emacs subprocesses.  I
think there are also packages from setting emacs internals within some
specified scope =E2=80=93 such as buffer-env.  "something-emacs-toolchain" =
is
imho a weird name for a(n implied) dependency for a particular emacs
package. =C2=A0

Other than that you could also spawn a special emacs for julia
development from its own manifest.  Would be a separate emacs process,
sure, but helps isolation :)

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#72994] manifest.scm and emacs-specific things
Resent-From: "Danny Milosavljevic" <dannym@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 21 Dec 2024 22:59:02 +0000
Resent-Message-ID: <handler.72994.B72994.173482188920047 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72994
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: ludo@HIDDEN, liliana.prikler@HIDDEN
Cc: cox.katherine.e+guix@HIDDEN, 72994 <at> debbugs.gnu.org, dannym@HIDDEN, andrew@HIDDEN
Received: via spool by 72994-submit <at> 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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tP8QC-0005DH-L3
	for submit <at> 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 <dannym@HIDDEN>) id 1tP8Q9-0005D7-Qk
 for 72994 <at> 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@HIDDEN>
 <87cyl49fbv.fsf@HIDDEN>
 <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
 <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@HIDDEN>
 <87zfn3rx8q.fsf@HIDDEN> <20241221183335.2740D1120E20@HIDDEN>
 <6913205399a12a20587ef1826a7fa44cc01d8b2a.camel@HIDDEN>
From: "Danny Milosavljevic" <dannym@HIDDEN>
User-Agent: ALL-INKL Webmail 2.11
X-SenderIP: 213.147.164.14
MIME-Version: 1.0
In-Reply-To: <6913205399a12a20587ef1826a7fa44cc01d8b2a.camel@HIDDEN>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-Id: <20241221225804.96AA91121508@HIDDEN>
Date: Sat, 21 Dec 2024 23:58:04 +0100 (CET)
X-Spamd-Bar: +
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#72994] manifest.scm and emacs-specific things
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Dec 2024 08:50:01 +0000
Resent-Message-ID: <handler.72994.B72994.173485737428945 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72994
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Danny Milosavljevic <dannym@HIDDEN>, ludo@HIDDEN
Cc: cox.katherine.e+guix@HIDDEN, 72994 <at> debbugs.gnu.org, dannym@HIDDEN, andrew@HIDDEN
Received: via spool by 72994-submit <at> debbugs.gnu.org id=B72994.173485737428945
          (code B ref 72994); Sun, 22 Dec 2024 08:50:01 +0000
Received: (at 72994) by debbugs.gnu.org; 22 Dec 2024 08:49:34 +0000
Received: from localhost ([127.0.0.1]:48967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tPHeX-0007Wn-Do
	for submit <at> debbugs.gnu.org; Sun, 22 Dec 2024 03:49:34 -0500
Received: from mail-wm1-f65.google.com ([209.85.128.65]:61832)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <liliana.prikler@HIDDEN>) id 1tPHeV-0007Wf-Gv
 for 72994 <at> debbugs.gnu.org; Sun, 22 Dec 2024 03:49:32 -0500
Received: by mail-wm1-f65.google.com with SMTP id
 5b1f17b1804b1-4367239aa86so13262975e9.3
 for <72994 <at> debbugs.gnu.org>; Sun, 22 Dec 2024 00:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1734857311; x=1735462111; darn=debbugs.gnu.org;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject
 :date:message-id:reply-to;
 bh=QmQJ1fyBOxRPDC+XbLfPR2VB5AD+W9BmN1CjhPpnsKg=;
 b=kWnWzovTzxrg0osm0zLQXQTDSclki3vI96KsqtaVmgoBvqLbvUh0oMacofE3GF7jqU
 j+hLzCVDwylTyDLzbgCVwffXdQWcWuHFpn7ZZgLucm2S8Qu7+eeCgKCW6efz4Ry3A/K+
 OB1T7GvVphSPIl/4HS1LcUtIgmuyKdBULhLPRTwr+AAlAZwBIFcR1NeAcm0UrsvwV3Up
 /PBaAPrMbU4gLO2IbQIzQv0ckWRNw0NyEoXqSTL3I9IvDFoXQrUB4a7KcBcvgBiOkvwq
 aCQaxDbp97FatJOnZxMLIXIF+TXSiHJQ6d/EU0/so4Qwld0uTubiyWb0QccZwqPXak2s
 V5Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1734857311; x=1735462111;
 h=mime-version:user-agent:content-transfer-encoding:references
 :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=QmQJ1fyBOxRPDC+XbLfPR2VB5AD+W9BmN1CjhPpnsKg=;
 b=lHYspBaI8IzIHXxv7qeO45BC2H3li3rogRqTI/Ml53AYUpa98TH5OlFoBW3MW1a9CK
 m6N3DM33mgyVVnz8e7M62mXw+Gt+eqoVGZhMK9scf8McJ6oXLJ/Pzwa9hbW5ibJ5MDUE
 rEMQ5ouXCD8dIPhTCvE+ukjik+EAosSNmHqhBY0lATDrPWxHpWXkWCXLVdhdDLFyoGC9
 iYcsDhuDg02iSncB/x5KYaek/7MkGpKJIYisb4YkxI7B4qNjsQ3H2J7vOPHgZ/9KEsNI
 31BS1NOlpcTV1pQbngEaNBQGjy/FOqrP5dG0Yt9oSGeJ3N56gczx3DKy09ZzesnxaKkG
 EWSA==
X-Forwarded-Encrypted: i=1;
 AJvYcCU1k8Fe+y5JOwu5wv30PWXsX1UqmEgyLPxKxuNXCCeVXqjz4x37izUloxzo+UrLZ4JM8ZCwaQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yxd8fbqKH5J6/glnCUPt+TBucEqYStffm1AgQsIIXNiQWF53KMK
 r0mmOia7+DCsLOggC81PnfOlVuYUsClVTn4HDwEZWMZEdQJsAJO3
X-Gm-Gg: ASbGnctd8HQ1hq9TQ60iyXyISPFwcv51WQW0DlqDVSj0oCIagVBLd7rWh5mK6hGxBRO
 hk48b0dFLS+Pl5uj09aIKjVc+O4hDAyWz1bm7BladkRRrMKlm0GFNTrOEDjpEWR7Ut1LyXQTwIP
 9TruI1jxf13ZAjFHM0TS3EBANVmH6T9JH3sLiI5PxHlwGo+ThRfQILGOmIjwFItxyliSvsvA6F+
 ZgZphe2RhaqORY0sc/WJyo9JhMbHpF+Q98DdYlkQcgJ/qWfmRPVg4GSX2K5Bkk0Urx5lY4NBqzr
 55iLqm+xxWuwrr6aZPH9Kux6vp346Us9
X-Google-Smtp-Source: AGHT+IHzpLH2/aNaNhx1MIap76vb8XwFDYRsG/scg3gMMXmf997jQ4WZJluRgc0qF8jz2TfM9KXSDw==
X-Received: by 2002:a05:600c:1d07:b0:435:192:63fb with SMTP id
 5b1f17b1804b1-4366854bf0cmr79648455e9.3.1734857310352; 
 Sun, 22 Dec 2024 00:48:30 -0800 (PST)
Received: from lumine.fritz.box (85-127-114-32.dsl.dynamic.surfer.at.
 [85.127.114.32]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4366127c4b0sm97876805e9.35.2024.12.22.00.48.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 22 Dec 2024 00:48:28 -0800 (PST)
Message-ID: <b94e53a98b468ff9c8dbff9e26497f2f2391f287.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Date: Sun, 22 Dec 2024 09:49:28 +0100
In-Reply-To: <20241221225804.96AA91121508@HIDDEN>
References: <58ce361528f55e5ad76ed7da4123525a9e9375e5.1725319687.git.dannym@HIDDEN>
 <87cyl49fbv.fsf@HIDDEN>
 <c2ee03afc41a15b6fa7624498dd32a50@HIDDEN>
 <63bc7d0629493cca55ee2d2b8623c7bd6d18995b.camel@HIDDEN>
 <87zfn3rx8q.fsf@HIDDEN>
 <20241221183335.2740D1120E20@HIDDEN>
 <6913205399a12a20587ef1826a7fa44cc01d8b2a.camel@HIDDEN>
 <20241221225804.96AA91121508@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Am Samstag, dem 21.12.2024 um 23:58 +0100 schrieb Danny Milosavljevic:
> Or every programmer would have to manually set up init.el to do:
>=20
> (setq buffer-env-script-name
> =C2=A0'("julia-snail-manifest.scm"
> =C2=A0=C2=A0 "python-lsp-manifest.scm"
> =C2=A0=C2=A0 "python-repl-manifest.scm"
> =C2=A0=C2=A0 "c-manifest.scm"
> =C2=A0=C2=A0 ...
> =C2=A0=C2=A0 "xyz-manifest.scm"
> =C2=A0=C2=A0 "manifest.scm"
> =C2=A0=C2=A0 ".envrc"))
>=20
> 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.
Guess I'm not a programmer=E2=84=A2 then. =20

> > 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 =E2=80=93 load paths pose no issue.
>=20
> I had a look at it now. Not sure it's the same situation. Is it?
>=20
> 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 :) ).
>=20
> In the case of julia the situation is:
>=20
> 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.
>=20
> (It has to do that because the julia grammar is complicated)
Geiser also has to connect to a running REPL at least for parts of its
functionality.  And it achieves a "good default" by having latest guile
as an input.  For Julia one could also solve this with an LSP probably
(which would require having that LSP running, tho), or tree-sitter, but
let's look at emacs-julia-snail in isolation, because that's the
package we're aiming to fix, no?

> 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).
>=20
> -----------------
>=20
> In my earlier attempts using julia-snail on guix master was even
> worse:
>=20
> 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
> (!!).
You're free to find a general fix to 20255, but I think that's outside
of scope given the workaround should well-known and well-documented by
now.  Quoting the manual on search paths

     Note: Notice that =E2=80=98GUIX_PYTHONPATH=E2=80=99 is specified as pa=
rt of the
     definition of the =E2=80=98python=E2=80=99 package, and _not_ as part =
of that of
     =E2=80=98python-numpy=E2=80=99.  This is because this environment vari=
able
     =E2=80=9Cbelongs=E2=80=9D to Python, not NumPy: Python actually reads =
the value of
     that variable and honors it.

     Corollary: if you create a profile that does not contain =E2=80=98pyth=
on=E2=80=99,
     =E2=80=98GUIX_PYTHONPATH=E2=80=99 will _not_ be defined, even if it co=
ntains
     packages that provide =E2=80=98.py=E2=80=99 files:

          $ guix shell python-numpy --search-paths --pure
          export PATH=3D"/gnu/store/...-profile/bin"

     This makes a lot of sense if we look at this profile in isolation:
     no software in this profile would read =E2=80=98GUIX_PYTHONPATH=E2=80=
=99.

> > If we can do something similar for julia, that'd be
> > great, but=E2=80=A6 I think leaking cstparser might be a no-no, would i=
t?
>=20
> What do you mean, exactly?
>=20
> If you mean this:
>=20
> 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 really don't think your conclusion follows from your premise.

> I mean we can do that but in my opinion it's not the best solution.
>=20
> If you mean that:
>=20
> 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.
>=20
> 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.
The problem with propagating another cstparser would be that Guix yells
at you for propagated inputs.  That's fine enough for the elisp stuff =E2=
=80=93
there's no real way around it =E2=80=93 but we tend to avoid it for non-eli=
sp
stuff in emacs packages.  Again: look at geiser.

> 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.
>=20
> 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!
>=20
> 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.
Describing how bad things are "in vivid detail" tends to only work for
those who already agree with you.  For me, all the extra emotional
baggage sounds like noise that I'd rather not deal with.  Mind you, I
can also be quite emotional on subjects, so I understand how you feel,
but I think appealing to emotions will not help us find workable
solutions.

As for those workable solutions, I think you could provide a julia that
is wrapped with a suffix env to include cstparser and tokenizer.  Let's
name that prospective package "julia-for-emacs-julia-snail" for now.=20
You would replace the julia binary in emacs-julia-snail with bin/julia
from julia-for-emacs-julia-snail just as you would with any other emacs
package (cf. geiser).

Alternatively, if julia-snail was a standalone package that offers the
julia side of things, we could install a "julia-snail-repl" to bin or
libexec and refer to that.  As far as I can see, julia-snail is not a
standalone julia package, though.

> > I mean, you could start pure guix shells as emacs subprocesses.
>=20
> Good idea!=C2=A0 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!
>=20
> (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)
I don't know how functional package management is supposed to interfere
with processes in your opinion.  I know that systemd goes long ways to
provide "clean" environments (which also break stuff unless you find
that one meaningful config file to edit, mind you), but we're not in a
position where we force everyone to use shepherd for everything.=C2=B9

Anyway, let's look at the actual problem within its actual scope.=20
Extrapolating from "emacs-julia-snail" not working as intended that
"actually, Guix is broken" is =E2=80=93 in my eyes at least =E2=80=93 a hug=
e leap I
don't want to take.

Cheers

=C2=B9 Yes, I know it's included in Guix Home.  No, that's not relevant to
my point.

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.