From: dannym@friendly-machines.com
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Katherine Cox-Buday <cox.katherine.e+guix@gmail.com>,
72994@debbugs.gnu.org,
Liliana Marie Prikler <liliana.prikler@gmail.com>,
Andrew Tropin <andrew@trop.in>
Subject: [bug#72994] [PATCH] gnu: emacs-julia-snail: Vendor julia libraries.
Date: Mon, 16 Sep 2024 20:01:16 +0200 [thread overview]
Message-ID: <c2ee03afc41a15b6fa7624498dd32a50@friendly-machines.com> (raw)
In-Reply-To: <87cyl49fbv.fsf@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)
next prev parent reply other threads:[~2024-09-16 18:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-03 0:02 [bug#72994] [PATCH] gnu: emacs-julia-snail: Vendor julia libraries Danny Milosavljevic
2024-09-16 8:24 ` Ludovic Courtès
2024-09-16 18:01 ` dannym [this message]
2024-09-17 17:19 ` Liliana Marie Prikler
2024-10-17 7:42 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c2ee03afc41a15b6fa7624498dd32a50@friendly-machines.com \
--to=dannym@friendly-machines.com \
--cc=72994@debbugs.gnu.org \
--cc=andrew@trop.in \
--cc=cox.katherine.e+guix@gmail.com \
--cc=liliana.prikler@gmail.com \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).