GNU bug report logs - #72994
[PATCH] gnu: emacs-julia-snail: Vendor julia libraries.

Previous Next

Full log

Message #26 received at 72994 <at> debbugs.gnu.org (full text, mbox):

From: "Danny Milosavljevic" <dannym <at> scratchpost.org>
To: ludo <at> gnu.org, liliana.prikler <at> gmail.com
Cc: cox.katherine.e+guix <at> gmail.com, 72994 <at> debbugs.gnu.org,
 dannym <at> friendly-machines.com, andrew <at> trop.in
Subject: Re: manifest.scm and emacs-specific things
Date: Sat, 21 Dec 2024 23:58:04 +0100 (CET)

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.

Previous Next

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