Re: Scripting guix in guile

[Konrad Hinsen <konrad.hinsen@fastmail.net>]

Hi Jesse and Ludo,

Jesse Gibbons <jgibbons2357@gmail.com> 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 <ludo@gnu.org> 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.