Re: Implementing the guix-dameon in Guile

["Ludovic Courtès" <ludo@gnu.org>]

Hi Christopher,

Christopher Baines <mail@cbaines.net> skribis:

> My plan is to focus on this over the next year. I left my previous day
> job quite a few months ago now to take a bit of a break, that's the main
> reason I've been able to spend more time trying to push forward some of
> the QA stuff. With some monetary support from NLNet [2], I'm planning to
> continue this break and focus for the next year on getting a Guile
> implementation of the guix-daemon written and adopted.
>
> 2: https://nlnet.nl/project/GuixDaemon-Guile/

Yay, this is great news!! But also: thank you for your long-term
commitment, it’s an invaluable contribution to the project.

> Rewrites are risky because you only get the value right at the end,
> therefore the priority is to get a minimal but viable implementation in
> Guile that can be switched to, and not to get distracted on adding or
> improving functionality unnecessarily. That is better done once the new
> implementation has been adopted.

In the past I wondered, as Maxim wrote, whether we could move
incrementally—after all, a fair bit of “the daemon” is already in Scheme
(there’s substitute support and other helps, plus (guix store …) etc.)
I’m not sure that’s feasible or desirable though.

My take today :-) is that ‘wip-guile-daemon’ is a great starting point.
We could aim towards having a minimal ‘guix daemon’ (space) command that
would coexist with ‘guix-daemon’ and that people could try out soonish
(I think Caleb got it to build derivations back then).  Eventually less
adventurous people will use it, and at some point it’ll be sufficiently
mature that we can default to ‘guix daemon’ instead of ‘guix-daemon’.

Technically, I think it should be a single-threaded Fibers program,
building on the experience we got from the Coordinator, shepherd, etc.
That should allow us to do everything in one process (in contrast, the
C++ implementation forks for every incoming connection, which then
significantly complicates the implementation of locking, etc.)

I imagine the daemon could be structured as a set of actors (it’s really
my thing these days ;-)), with an eye on facilitating code sharing and
interaction with the Coordinator, Cuirass, and all that.

I hope this makes sense.  Time will tell!

Ludo’.