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

Previous Next

Full log

View this message in rfc822 format

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Danny Milosavljevic <dannym <at> scratchpost.org>, ludo <at> gnu.org
Cc: cox.katherine.e+guix <at> gmail.com, 72994 <at> debbugs.gnu.org, dannym <at> friendly-machines.com, andrew <at> trop.in
Subject: [bug#72994] manifest.scm and emacs-specific things
Date: Sat, 21 Dec 2024 21:20:51 +0100

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.
> 
> (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?
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 – load paths
pose no issue.  If we can do something similar for julia, that'd be
great, but… 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 – such as buffer-env.  "something-emacs-toolchain" is
imho a weird name for a(n implied) dependency for a particular emacs
package.  

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

Previous Next

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