A friendlier API for operating-system declarations

[Edouard Klein]

Dear Guixers,

For my clients and my own use, I use a layer on top of operating-system
declarations in which I create functions that take an os as a first
argument, and return an os.

With the help of the handy -> macro, I can chain them, thus allowing an
easy stacking of multiple "roles" or "functionalities" on the same
machine, and an easy transfer of said functionality to another machine:
just cut and paste one line from one declaration to the other.

I have written a tutorial for my clients here:

https://guix-hosting.com/docs/tuto/getting-started.html

that gives an example of what an os configuration may look like:
#+begin_src scheme
(->
 (minimal-ovh "ssh-rsa AAASomethingSomething== root@minimal-ovh")
 (http-static-content "sub2.example.com" #:to-dir "/srv/sub2")
 (http-static-content "sub1.example.com" #:to-dir "/srv/sub1/")
 (add-services my-db))
#+end_src

The code of the function is on my channel:
https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm

After a few months of experience, and positive feedback from my clients,
my question to you guys is: would you be interested in mainlining this,
or should I keep my development efforts separate in my channel ?

I do think this API is easier than manipulating services, and although
extendable services are awesome and a very nifty piece of engineering,
they require quite a good knowledge of scheme and take a while to be
used to, while this new API, while way less powerful, lowers the barrier
to entry for newcomers.

They are an easy way to maintain a declarative whole operating system
configuration, with a syntax similar enough to docker and ansible that
sysadmins familiar with it can quickly get up and running, thus exposing
more people to Guix.

What do you think ?

Cheers,

Edouard.

[PATCH] gnu: Add tree-sitter-heex.

[ivan-p-sokolov]

gnu/packages/tree-sitter.scm (tree-sitter-heex): New variable.
---
 gnu/packages/tree-sitter.scm | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gnu/packages/tree-sitter.scm b/gnu/packages/tree-sitter.scm
index 8dda7737ca..b91345bb36 100644
--- a/gnu/packages/tree-sitter.scm
+++ b/gnu/packages/tree-sitter.scm
@@ -301,6 +301,13 @@ (define-public tree-sitter-elixir
#:commit commit
#:license (list license:asl2.0 license:expat
 
+(define-public tree-sitter-heex
+  (tree-sitter-grammar
+   "heex" "Heex"
+   "00330rgg67fq0d9gk1yswj78d9mn1jvvjmmy1k7cxpvm5993p3sw"
+   "0.6.0"
+   #:repository-url "https://github.com/phoenixframework/tree-sitter-heex";))
+
 (define-public tree-sitter-bash
   (tree-sitter-grammar
"bash" "Bash"
-- 
2.39.2

Re: shepherd service works on host but fails inside system container

[Vladilen Kozin]

I now have a hypothesis as to what's happening. Could someone confirm or
disprove and maybe suggest a solution or point at existing workarounds.

Host and container will share the exact same kernel that's unsurprisingly
already running, so the above has nothing to do with kernel modules or
settings. Fwiw I figured a way to find where kernel modules reside by doing:

$ sudo dmesg | grep -i "kernel command line"
which shows where current system is inside the store and relevant
/lib/modules will be under it. We could then
--expose=/gnu/store/hash-system/lib/modules=/lib/modules if we wanted to.

Real problem, IIUC, is with capabilities. Notion of "container" can be
misleading and evokes thoughts of "vm" when in practice its just a process
with some isolation applied to it. So, presently I'm guessing container
Shepherd maybe PID 1 inside its isolated environment, but from the host pow
it is just a process and one that unlike our host's shepherd may lack
certain capabilities and privileges to e.g. create new devices or load
kernel modules on request, etc. In the sense of
https://man7.org/linux/man-pages/man7/capabilities.7.html maybe?

Am I on the right track? But then, how does one test services like that
that may require ability to modify devices etc? Have we "outgrown"
container and ought to `guix system vm` for such services? Or is there a
way to bless container shepherd with necessary capabilities? If not from
`guix system container` command line, then perhaps dropping down to the
underlying programmatic interface i.e. whatever `guix system container`
ends up calling to containerize a system?

Thanks


On Wed, 22 Mar 2023 at 10:20, Vladilen Kozin 
wrote:

> Hello guix.
>
> I put together a tailscale system service that's meant to start a
> tailscale daemon managed by the system shepherd, that is to say that my
> `tailscaled-service-type` specifies `(service-extension
> shepherd-root-service-type tailscaled-shepherd-service)`, where
> `tailscaled-shepherd-service` creates a `shepherd-service` with (provision
> '(tailscaled)) and (requirement '(networking)).
>
> I tested it by lowering to store via `shepherd-service-file` and then
> loading the generated script via `sudo herd load root ...`. This works fine
> and the daemon starts without a problem.
>
> Next, I try to spawn tailscaled as part of my OS definition:
> (services (cons* (service tailscaled-service-type
> (tailscaled-configuration)) %base-services))
> ;; tried %desktop-services too
>
> To test, we create a container:
> sudo guix system -K -L /home/vlad/Code/fullmeta-guix/channel container
> os.scm --network --expose=/dev/net=/dev
>
> Earlier runs had it complaining that /dev/net/tun was missing, so I
> exposed that. Dunno if that's how I'm supposed to handle this. Now,
> /var/log/messages show:
>
> Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48 Linux
> kernel version: 5.18.10
> Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48 is
> CONFIG_TUN enabled in your kernel? `modprobe tun` failed with:
> Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48
> wgengine.NewUserspaceEngine(tun "tailscale0") error:
> tstun.New("tailscale0"): operation not permitted
>
> I feel like maybe I'm missing some kernel modules, but I would've expected
> host and container to share the kernel, so I dunno. In fact, when I
> randomly attempted adding (kernel-arguments (cons* "CONFIG_TUN=m"
> %default-kernel-arguments)) to my os definition, resulting script hash came
> out the same, which tells me, containers don't even look at these kernel
> params when generating a script.
>
> Any guesses as to why this works under host but not inside container?
>
> Relatedly, does anyone have a nicer workflow they use to define and test
> shepherd services? Such containerization was the next step in testing the
> service and would've been ok were it not for the above failure, but the
> initial indirection with lowering to store, then `sudo herd load root ...`
> is a bit too involved and "indirect" for my liking as well - anyone has an
> improved way of developing shepherd services?
>
> Thanks!
> --
> Best regards
> Vlad Kozin
>


-- 
Best regards
Vlad Kozin

GSoC 2023 | Web Interface to Configure Guix

[Malik Talha]

Hello there,

I hope you are doing well. I am Malik Talha, a final-year student at the
National University of Computer & Emerging Sciences (FAST), pursuing an
undergraduate in Computer Science.'

I am interested to design and develop a web-based interface to enable the
configuration of Guix systems. I have been researching Guix for the past
week and found it quite interesting and would love to work on this project.

I have a great amount of experience in developing GUIs, in fact, I also
have certification in UI/UX design fundamentals from Google (Coursera).
During my time as a student, I have mainly worked on Linux (Ubuntu, Mint,
etc.) for my development of C/C++ and Web Apps. I have developed multiple
applications using HTML5 and other web development stacks and also worked
with Qt framework to create a Management System in past.

It would be great if I can get guidance and mentorship to work on this
project as part of GSoC. Looking forward to hearing from you.

Yours truly,
-- 
[image: Profile image]
Malik Talha
B.Sc. Computer Science (Student)
[image: email] maliktalha...@outlook.com
[image: website] https://maliktalha.me
[image: linkedIn]  [image: github]
 [image: twitter]

shepherd service works on host but fails inside system container

[Vladilen Kozin]

Hello guix.

I put together a tailscale system service that's meant to start a tailscale
daemon managed by the system shepherd, that is to say that my
`tailscaled-service-type` specifies `(service-extension
shepherd-root-service-type tailscaled-shepherd-service)`, where
`tailscaled-shepherd-service` creates a `shepherd-service` with (provision
'(tailscaled)) and (requirement '(networking)).

I tested it by lowering to store via `shepherd-service-file` and then
loading the generated script via `sudo herd load root ...`. This works fine
and the daemon starts without a problem.

Next, I try to spawn tailscaled as part of my OS definition:
(services (cons* (service tailscaled-service-type
(tailscaled-configuration)) %base-services))
;; tried %desktop-services too

To test, we create a container:
sudo guix system -K -L /home/vlad/Code/fullmeta-guix/channel container
os.scm --network --expose=/dev/net=/dev

Earlier runs had it complaining that /dev/net/tun was missing, so I exposed
that. Dunno if that's how I'm supposed to handle this. Now,
/var/log/messages show:

Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48 Linux
kernel version: 5.18.10
Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48 is
CONFIG_TUN enabled in your kernel? `modprobe tun` failed with:
Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48
wgengine.NewUserspaceEngine(tun "tailscale0") error:
tstun.New("tailscale0"): operation not permitted

I feel like maybe I'm missing some kernel modules, but I would've expected
host and container to share the kernel, so I dunno. In fact, when I
randomly attempted adding (kernel-arguments (cons* "CONFIG_TUN=m"
%default-kernel-arguments)) to my os definition, resulting script hash came
out the same, which tells me, containers don't even look at these kernel
params when generating a script.

Any guesses as to why this works under host but not inside container?

Relatedly, does anyone have a nicer workflow they use to define and test
shepherd services? Such containerization was the next step in testing the
service and would've been ok were it not for the above failure, but the
initial indirection with lowering to store, then `sudo herd load root ...`
is a bit too involved and "indirect" for my liking as well - anyone has an
improved way of developing shepherd services?

Thanks!
-- 
Best regards
Vlad Kozin

Hello Guix!

[Vijaya Anand]

Hi Everyone,

I am Vijaya Anand, a mathematics undergraduate studying in IITK, India. I
am interested in the topics distributed systems and cryptography and have
been self-reading on these topics a lot recently. I wanted to participate
in GSoC this summer and while browsing some interesting organizations, I
came across guix and the project 'Decentralized Substitute Distribution'
sparked my interest a lot. I have recently been interacting with
pukkamustard, who is mentoring this project, and got to know a handful
about this project and how we can distribute substitutes using any p2p
network using ERIS. This project matched my interests and I'm very excited
to work on this. Hoping to interact with the community and contribute to
guix!

Thank you
Vijaya Anand

Re: shepherd service works on host but fails inside system container

[Vladilen Kozin]

I guess capabilities aren't handled by container creation code yet:
https://github.com/guix-mirror/guix/blob/master/gnu/build/linux-container.scm#L262


IIUC this would also effect the idea of isolating system services as
described in
https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/.

It may require deeper understanding of Linux caps, namescase and how it all
handled by Guix code, I suppose. Not something I'll be able to pull off
without hand-holding from core devs, sigh.

On Wed, 22 Mar 2023 at 12:14, Vladilen Kozin 
wrote:

> I now have a hypothesis as to what's happening. Could someone confirm or
> disprove and maybe suggest a solution or point at existing workarounds.
>
> Host and container will share the exact same kernel that's unsurprisingly
> already running, so the above has nothing to do with kernel modules or
> settings. Fwiw I figured a way to find where kernel modules reside by doing:
>
> $ sudo dmesg | grep -i "kernel command line"
> which shows where current system is inside the store and relevant
> /lib/modules will be under it. We could then
> --expose=/gnu/store/hash-system/lib/modules=/lib/modules if we wanted to.
>
> Real problem, IIUC, is with capabilities. Notion of "container" can be
> misleading and evokes thoughts of "vm" when in practice its just a process
> with some isolation applied to it. So, presently I'm guessing container
> Shepherd maybe PID 1 inside its isolated environment, but from the host pow
> it is just a process and one that unlike our host's shepherd may lack
> certain capabilities and privileges to e.g. create new devices or load
> kernel modules on request, etc. In the sense of
> https://man7.org/linux/man-pages/man7/capabilities.7.html maybe?
>
> Am I on the right track? But then, how does one test services like that
> that may require ability to modify devices etc? Have we "outgrown"
> container and ought to `guix system vm` for such services? Or is there a
> way to bless container shepherd with necessary capabilities? If not from
> `guix system container` command line, then perhaps dropping down to the
> underlying programmatic interface i.e. whatever `guix system container`
> ends up calling to containerize a system?
>
> Thanks
>
>
> On Wed, 22 Mar 2023 at 10:20, Vladilen Kozin 
> wrote:
>
>> Hello guix.
>>
>> I put together a tailscale system service that's meant to start a
>> tailscale daemon managed by the system shepherd, that is to say that my
>> `tailscaled-service-type` specifies `(service-extension
>> shepherd-root-service-type tailscaled-shepherd-service)`, where
>> `tailscaled-shepherd-service` creates a `shepherd-service` with (provision
>> '(tailscaled)) and (requirement '(networking)).
>>
>> I tested it by lowering to store via `shepherd-service-file` and then
>> loading the generated script via `sudo herd load root ...`. This works fine
>> and the daemon starts without a problem.
>>
>> Next, I try to spawn tailscaled as part of my OS definition:
>> (services (cons* (service tailscaled-service-type
>> (tailscaled-configuration)) %base-services))
>> ;; tried %desktop-services too
>>
>> To test, we create a container:
>> sudo guix system -K -L /home/vlad/Code/fullmeta-guix/channel container
>> os.scm --network --expose=/dev/net=/dev
>>
>> Earlier runs had it complaining that /dev/net/tun was missing, so I
>> exposed that. Dunno if that's how I'm supposed to handle this. Now,
>> /var/log/messages show:
>>
>> Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48
>> Linux kernel version: 5.18.10
>> Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48 is
>> CONFIG_TUN enabled in your kernel? `modprobe tun` failed with:
>> Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48
>> wgengine.NewUserspaceEngine(tun "tailscale0") error:
>> tstun.New("tailscale0"): operation not permitted
>>
>> I feel like maybe I'm missing some kernel modules, but I would've
>> expected host and container to share the kernel, so I dunno. In fact, when
>> I randomly attempted adding (kernel-arguments (cons* "CONFIG_TUN=m"
>> %default-kernel-arguments)) to my os definition, resulting script hash came
>> out the same, which tells me, containers don't even look at these kernel
>> params when generating a script.
>>
>> Any guesses as to why this works under host but not inside container?
>>
>> Relatedly, does anyone have a nicer workflow they use to define and test
>> shepherd services? Such containerization was the next step in testing the
>> service and would've been ok were it not for the above failure, but the
>> initial indirection with lowering to store, then `sudo herd load root ...`
>> is a bit too involved and "indirect" for my liking as well - anyone has an
>> improved way of developing shepherd services?
>>
>> Thanks!
>> --
>> Best regards
>> Vlad Kozin
>>
>
>
> --
> Best regards
> Vlad Kozin
>


-- 
Best regards
Vlad Kozin

proper way to satisfy service dependencies

[Vladilen Kozin]

Hi.

When I have a package whose only purpose in life is to be started as daemon
by e.g. Shepherd how would I satisfy its binary dependencies when defining
a service? For packages this is normally part of their (inputs ...) slot,
but IIUC this only makes it so these dependencies will be added to the same
profile used when installing said package. But when I define a service
there's no profile to speak of, so as part of the service definition I need
to make sure I satisfy its dependencies. Say, when I start a network
service that needs to run `iptables`.

The one time I ran into this, I managed by pulling `iptables` module into
derivation context and adding its /sbin to PATH in:
(make-forkexec-constructor ...
  #:environment-variables
  (let ((iptables (string-append #$iptables "/sbin")))
 ... extend PATH= here ...))

Another approach could be wrapping the daemon binary itself as part of its
package definition, so something like (wrap-program ... ) that makes sure
`iptables` is in PATH of that wrapper.

I kinda wish there was a simpler way to just declare what you need as part
of service definition.

What's the preferred approach here?

Thanks
-- 
Best regards
Vlad Kozin

Re: more package transformations: overrides

[Ricardo Wurmus]

Maxim Cournoyer  writes:

>> Considering that the transformations API assumes that you understand
>> that higher order functions exist and what to do with them, I think it
>> would be good to offer a slightly less advanced method of overriding
>> packages.
>>
>> Manifests can do anything, but this also makes them rather intimidating
>> for many of my colleagues.
>
> OK; then my question would be: why stop at transformations?  Perhaps we
> could simply have a way to feed arbitrary guix command line arguments
> from a file, e.g.
>
> guix shell --args-file=my-arguments.txt

The transformations command line options are rather verbose:

  --with-input=python-pytorch=python-pytorch-with-extra-features

I think it would improve usability to be able to use the *same* names in
an override file.  Got a package with name “python-pytorch” in that
file?  It replaces “python-pytorch” in the graph.

~~

On the separate topic of reading arguments from elsewhere, though, I
think being able to read arguments from stdin could be useful.  Without
having to add a new option one could then do

guix shell < my-arguments.txt

-- 
Ricardo

Re: A friendlier API for operating-system declarations

[Josselin Poiret]

Hi Edouard,

Edouard Klein  writes:

> #+begin_src scheme
> (->
>  (minimal-ovh "ssh-rsa AAASomethingSomething== root@minimal-ovh")
>  (http-static-content "sub2.example.com" #:to-dir "/srv/sub2")
>  (http-static-content "sub1.example.com" #:to-dir "/srv/sub1/")
>  (add-services my-db))
> #+end_src
>
> The code of the function is on my channel:
> https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm
>
> After a few months of experience, and positive feedback from my clients,
> my question to you guys is: would you be interested in mainlining this,
> or should I keep my development efforts separate in my channel ?

I am quite in favor of using operating-system transformations rather
than inheritance, because they're composable!  This could be leveraged
to get a nice CLI API as well.

> I do think this API is easier than manipulating services, and although
> extendable services are awesome and a very nifty piece of engineering,
> they require quite a good knowledge of scheme and take a while to be
> used to, while this new API, while way less powerful, lowers the barrier
> to entry for newcomers.

By this, do you mean that there's no way with your syntax to modify a
given service?  Is there a reason for this?  It does seem to me that it
could probably be done.

> They are an easy way to maintain a declarative whole operating system
> configuration, with a syntax similar enough to docker and ansible that
> sysadmins familiar with it can quickly get up and running, thus exposing
> more people to Guix.
>
> What do you think ?

You've got me interested :) especially since you already have customer
feedback!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Guix QA: build status "unknown"

[Andy Tai]

I don't know if it is just me, but Guix QA recently seems to always
show build status unknown when what really happens was the build
succeeds on both x86-64 and aarch64 but on other platforms it was in
"scheduled" state but the scheduled build never actually got run.   In
any case thanks to the reviewers/committers some of my patches got
reviewed and committed in this state.

It is just the build status is misleading.   If just x86-64 and
aarch64 builds are used to determine if a patch builds successfully
then the badge should reflect such.

Re: Hello Guix!

[(]

On Tue Mar 21, 2023 at 11:21 AM GMT, Vijaya Anand wrote:
> I am Vijaya Anand, a mathematics undergraduate studying in IITK, India. I
> am interested in the topics distributed systems and cryptography and have
> been self-reading on these topics a lot recently. I wanted to participate
> in GSoC this summer and while browsing some interesting organizations, I
> came across guix and the project 'Decentralized Substitute Distribution'
> sparked my interest a lot. I have recently been interacting with
> pukkamustard, who is mentoring this project, and got to know a handful
> about this project and how we can distribute substitutes using any p2p
> network using ERIS. This project matched my interests and I'm very excited
> to work on this. Hoping to interact with the community and contribute to
> guix!

Hello Vijaya!  More decentralisation for substitutes is definitely something we
need; it's been discussed a lot, but there's not been much action on it, as far
as I can tell, so contributions in that space would be very welcome :)

-- (


signature.asc
Description: PGP signature

Re: A friendlier API for operating-system declarations

[Edouard Klein]

Hi Josselin,

Josselin Poiret  writes:

> [[PGP Signed Part:Undecided]]
> Hi Edouard,
>
> Edouard Klein  writes:
>
>> #+begin_src scheme
>> (->
>>  (minimal-ovh "ssh-rsa AAASomethingSomething== root@minimal-ovh")
>>  (http-static-content "sub2.example.com" #:to-dir "/srv/sub2")
>>  (http-static-content "sub1.example.com" #:to-dir "/srv/sub1/")
>>  (add-services my-db))
>> #+end_src
>>
>> The code of the function is on my channel:
>> https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm
>>
>> After a few months of experience, and positive feedback from my clients,
>> my question to you guys is: would you be interested in mainlining this,
>> or should I keep my development efforts separate in my channel ?
>
> I am quite in favor of using operating-system transformations rather
> than inheritance, because they're composable!  This could be leveraged
> to get a nice CLI API as well.
>

I hadn't thought of that but now that you mention it, starting a basic
web server or database, isolated in a container, directly from the
command line may come in handy sometimes. This is a good idea ! I'll
think about how to achieve this :)

In the meantime something like:

#+begin_src bash
guix system container -e "(begin (use-modules (beaver system))
(http-static-content minimal-container))" --share=somedir=/var/www
#+end_src

Will spin up such a server. Kind of like python3 -m http.server, but
without the security flaws (you get a full blown nginx), and isolated in
a way that even if your process gets owned, it's only an unpriviledged
user in a container.


>> I do think this API is easier than manipulating services, and although
>> extendable services are awesome and a very nifty piece of engineering,
>> they require quite a good knowledge of scheme and take a while to be
>> used to, while this new API, while way less powerful, lowers the barrier
>> to entry for newcomers.
>
> By this, do you mean that there's no way with your syntax to modify a
> given service?  Is there a reason for this?  It does seem to me that it
> could probably be done.
>

I'm not sure I understand your question.

What I meant is that my proposal is only syntactic sugar over the
existing system, and not meant to replace it.

The existing system is actually very good and the way you
can define how to collate the instances of a given service type, even if
they are instanciated far away from one another, likely by different
authors is really clever and well made. I'm talking here about things
like how you can easily request that a new user be made for your
service, and account-service-type will collate all the users that need
to exist, and actually get the job done. Basically what fold-services does.

I just want to hide all of this complexity for people who just want to
activate one or more instances of a service coded up by somebody else.

If by modifying a service you mean the parameters like the port ones
listen to, or the directory the data should be put in etc. the functions
just take keyword parameters and pass them to the underlying
*-configuration scheme record. They are quite easy to edit and compose.
Maybe we could even devise a semi-automated way of generating one function
for every *-configuration structure that exists.

See
https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/system.scm#L236

how http-static-content is basically just a wrapper over 
nginx-server-configuration.

If you meant editing the service after the function has run, you then
need to inspect the operating-system record and fall back to the
original API, by finding the service in the record and editing its
members, but that seems complex to me. I'm probably misunderstanding
the use case.



>> They are an easy way to maintain a declarative whole operating system
>> configuration, with a syntax similar enough to docker and ansible that
>> sysadmins familiar with it can quickly get up and running, thus exposing
>> more people to Guix.
>>
>> What do you think ?
>
> You've got me interested :) especially since you already have customer
> feedback!
>

Thanks :)



Cheers,

Edouard.
> Best,

Re: A friendlier API for operating-system declarations

[Liliana Marie Prikler]

Am Donnerstag, dem 23.03.2023 um 09:06 +0100 schrieb Edouard Klein:
> After a few months of experience, and positive feedback from my
> clients, my question to you guys is: would you be interested in
> mainlining this, or should I keep my development efforts separate in
> my channel ?
Having just dropped a series of "old-style" service procedures, I don't
think that maintaining a separate API on the mainline is a good idea.

> I do think this API is easier than manipulating services, and
> although extendable services are awesome and a very nifty piece of
> engineering, they require quite a good knowledge of scheme and take a
> while to be used to, while this new API, while way less powerful,
> lowers the barrier to entry for newcomers.
I see how this style (and a similar one that has already been shown for
guix home) can improve configuration file clarity and that's a good
thing.  On the other hand, it looks like you currently have to manually
craft a lot of the procedures that go into the -> syntax and that's...
well, not so good.

If we could enable this style easier – say if we made it so that
define-configuration and service-type also emitted ready-to-use
constructors to use with a keyword style at little extra cost other
than compilation time, I think that'd be a net positive for everyone
involved.

Cheers