[bug#72994] manifest.scm and emacs-specific things

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

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:
> 
> (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.
Guess I'm not a programmer™ then.  

> > 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)
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).
> 
> -----------------
> 
> 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
> (!!).
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 ‘GUIX_PYTHONPATH’ is specified as part of the
     definition of the ‘python’ package, and _not_ as part of that of
     ‘python-numpy’.  This is because this environment variable
     “belongs” 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 ‘python’,
     ‘GUIX_PYTHONPATH’ will _not_ be defined, even if it contains
     packages that provide ‘.py’ files:

          $ guix shell python-numpy --search-paths --pure
          export PATH="/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 ‘GUIX_PYTHONPATH’.

> > 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 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.
> 
> 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.
The problem with propagating another cstparser would be that Guix yells
at you for propagated inputs.  That's fine enough for the elisp stuff –
there's no real way around it – but we tend to avoid it for non-elisp
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.
> 
> 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.
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. 
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.
> 
> 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)
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.¹

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

Cheers

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