Efficient iterative shepherd service development ?

Efficient iterative shepherd service development ?

[Nicolas Odermatt-Lemay]

Hello Guix hackers !

I find myself spending a lot of time developing custom service types and,
being a novice in Guile, I feel like I need to add a few lines of code at a
time, test, and repeat.

So far I've been working on the new service in its own file and I added
this service in my operating-system definition. I then use `guix system
reconfigure ...' to test the service.
This workflow works but it is time consuming. It also adds a new operating
system generation at each iteration, which is unnecessary.
I also don't like the fact that I'm putting some code in my
operating-system definition that I wasn't able to test beforehand.

So I'd like to know the "Guix way", or just a more efficient way to do this
type of development. Note that I'm mostly interested in service types that
extend shepherd-service-type.

My end goal would be to call something like `(test-my-service
"path/to/service.scm")' and have it stop the service if it's running,
reload its definition according to what's in "path/to/service.scm" and
restart it.

Would this be a way to go ? If it is, how could this be implemented ?
And do you have any other advice ?

Thanks !

Re: Efficient iterative shepherd service development ?

[Felix Lechner via]

Hi Nicholas,

On Mon, Aug 05 2024, Nicolas Odermatt-Lemay wrote:

> So I'd like to know the "Guix way", or just a more efficient way to do
> this type of development.

I'd use the Shepherd REPL. [1]

You'll have to install the executables you need into the system profile,
since their store paths may not be known inside the REPL.

Kind regards
Felix

[1] https://www.gnu.org/software/shepherd/manual/html_node/REPL-Service.html

Re: Efficient iterative shepherd service development ?

[Carlo Zancanaro]

On Mon, Aug 05 2024, Nicolas Odermatt-Lemay wrote:
> Would this be a way to go ? If it is, how could this be implemented ?
> And do you have any other advice ?

When I work on services I usually use "guix system vm" and/or "guix
system container". These allow me to instantiate a system with the
service(s) that I'm working on without risking breaking my real system.
It also makes cleaning up between tests much simpler: I just kill the
VM/container.

I find it easier to write a minimal operating-system definition, rather
than using one of my real system definitions, but you can do it either
way.

Carlo