Re: Setting up a geiser development environment

[Fredrik Salomonsson <plattfot@posteo.net>]

Hej,

Einar Largenius <jaadu@lysator.liu.se> writes:

> Hi, thanks for the reply.
>
> I want to have geiser accessible. It would make trailing and error and
> finding symbols much easier.
>
>>     (use-modules (gnu packages))
>
> I forgot to include this in my example. The Geiser repl tells me there are
> no code for the module. It works fine when using guix repl though.
>
> I checked the value of %load-path when I start geiser and compare it
> with the value I get with guix repl. They look very similar except the
> load path provided with guix repl is provides an additional path:
>
>     "/gnu/store/6qfk8gs9qyk5vx79bb62gf4gz9n7wp95-guix-module-union/share/guile/site/3.0"
>
> I don't find anything similar in my .guix-profile.

Yeah, it is the same on my machine. I'm using guix on a foreign distro.
I poked around with this a bit yesterday but couldn't find a satisfying
solution. But my solution for #2 came quite close.

>
> I see a few alternatives.
>
> 1. Identify which package includes this "guix-module-union" and add it
>    to my profile.

The one that includes that is guix itself. And that is stamped into the
guix commandline tool.

See:

    cat `which guix`

Or guix/self.scm:581 and guix/self.scm:515 in the source code.

Closest you get is adding guix to a temporary profile like

    guix shell guix guile

I would not recommend adding guix to your .guix-profile, as that messes
up quite a few things. The guix you install is not neccessary the guix
you are running. It gets really meta when you install your package
manager with your package manager :). So I would recommend using
`guix shell` for that.

> 2. Dynamically add the path using wildcards to my .guile startup file.
>    Adding a hardcoded path will break this during every update.

This will not break during every update, but highly likely to break when
you run `guix gc`. As it is then paths are deleted in the store.

Best I came up with is to first export the development environment of
guix using:

    guix shell guile --development guix --export-manifest

This will give you something that looks like this:

---8<---------------------------------------------------------------------------
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(concatenate-manifests
  (list (specifications->manifest (list "guile"))
        (package->development-manifest
          (specification->package "guix"))))
--------------------------------------------------------------------------->8---

Then add your current guix's guile paths to the guile environment
variables (assuming you have bash or something equivalent):

---8<---------------------------------------------------------------------------
export GUILE_LOAD_PATH=$HOME/.config/guix/current/share/guile/site/3.0:$GUILE_LOAD_PATH
export GUILE_LOAD_COMPILED_PATH=$HOME/.config/guix/current/lib/guile/3.0/site-ccache:$GUILE_LOAD_COMPILED_PATH
--------------------------------------------------------------------------->8---

Just adding the current guix's guile paths to guile will not include the
dependencies guix needs. E.g. you'll see error messages like these `no
code for module (gcrypt hash)` when trying to use (gnu packages).

This is what `--development guix` in guix shell or
`(package->development-manifest (specification->package "guix"))` in the
manifest do. I.e. it will specify the development environment for guix.

Then you can either use `guix shell -m <manifest>` to setup the package
environment or `guix package -m <manifest>` to install the packages to
your .guix-profile. Note that `guix package -m <manifest>` will remove
all packages installed to the profile that are not listed in the
manifest. So do a `guix package --export-manifest` first and combine
that with the manifest above.

An alternative to the autogenerated manifest from `guix shell`, is to
simply fetch the propagated-inputs from the guix package and add that to
the manifest:
---8<---------------------------------------------------------------------------
(use-modules
  (guix packages)                    ;; For package-propagated-inputs
  (gnu packages)                     ;; For specifications->manifest
  (gnu packages package-management)) ;; Access to the guix package

(specifications->manifest
 `(
   "guile"
   ,@(map car (package-propagated-inputs guix))
   ))
--------------------------------------------------------------------------->8---

The (map car …) is to just return the name of each propagated-input of
the guix package. As for the `(…) and ,@ see the quasiquote section in
the guile manual[0].

[0] https://www.gnu.org/software/guile/manual/html_node/Expression-Syntax.html

> 3. Change so that geiser uses "guix repl" instead of "guile" when
>    starting a repl.
>

I quickly tested this by setting `geiser-guile-binary` to "guix repl".
But it expects a name to a binary and not a binary with arguments. It is
probably doable but would require more hacking to get this to work.

> I lack the experience with both guix and scheme so none of the above
> would be easy to do for me. The last alternative would probably be the
> easiest for me.
>

I would say try my suggestion for #2. But if you just want to quickly
get going with playing around with the repl. Use:

    guix shell guix guile -- emacs

A caveat with the guix shell command is that the guix you get is most
likely not the same guix you are running outside of the guix shell
environment.

And I'm far from an expert in either guix or guile so there are probably
better ways to set this up.

-- 
s/Fred[re]+i[ck]+/Fredrik/g