[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scripting guix in guile
From: |
Konrad Hinsen |
Subject: |
Re: Scripting guix in guile |
Date: |
Wed, 04 Sep 2019 12:42:41 +0200 |
Hi Jesse and Ludo,
Jesse Gibbons <address@hidden> writes:
> 1. Tell your audience to call "guile <scriptname>" when running the
> script.
That's very reasonable, but...
> This does not garuntee guix is in their GUILE_LOAD_PATH though, so you
> will either need to tell them to add a segment to .bashrc to add the
> guix source location to their GUILE_LOAD_PATH or have them use the -L
> flag to have guile search that directory.
that sounds a bit complicated to explain, especially since they first
have to figure out the correct path segment to add, which depends on how
Guix was installed.
> 2. Instruct the audience to use features of guix when playing with the
> script:
Some of those are in fact my main topic (which will be part of a
tutorial on managing software environments for reproducible research).
But I want to keep technical details to a minimum for an introduction to
Guix.
> 3. I think you can use autogen to find out where guile and guix are
> located and use that location in the shebang and in a script that adds
> guix to GUILE_LOAD_PATH. This is a bit complicated though, and you will
> need to make sure your audience has autogen before they can do
> anything.
I don't even use autogen myself, so that's perhaps not the right
approach...
Ludovic Courtès <address@hidden> writes:
>> 1. What to put into the #! line to locate Guile.
>
> On Guix System #!/run/current-system/profile/bin/guile is very likely to
> work :-), but on other systems you could use “#!/usr/bin/env guile” I
> suppose.
True. But I'd prefer something that works on both!
>> 2. How to construct the load path to make sure it includes
>> Guix as installed under $HOME/.config/guix/current
>
> That’s indeed annoying. I think we should add ‘-s’ and similar flags
> that ‘guile’ supports to ‘guix repl’.
That sounds like a good idea, though I'd probably use "guix script" or
something similar rather than overload "repl".
> In the meantime, as Jesse suggested, you could arrange to have both
> ‘guix’ (the package) and ‘guile’ in a profile, such that Guix and its
> dependencies are available in $GUILE_LOAD_PATH.
That's what I thought would work, but it doesn't:
$ which guix
/home/hinsen/.guix-profile/guix
$ which guile
/home/hinsen/.guix-profile/guile
$ echo $GUILE_LOAD_PATH
/home/hinsen/.guix-profile/share/guile/site/2.2
$ ls $GUILE_LOAD_PATH
emacs-guix emacs-guix.scm gcrypt
That's with a Guix install under Ubuntu.
>´ As for inspecting the installed packages, the entry point is (guix
> profiles), which has everything you need to grab info about a profile.
Indeed, together with (guix packages) that's enough for exploring
a profile or environment, which is my main topic. My scripts
output stuff like (transitive-manifest-entries ...) or
(package-closure ...) in a readable format, to let users get a better
idea of what their code really depends on, and how.
Cheers,
Konrad.