[bug#53466] [PATCH] home: Add redshift service.

[Ludovic Courtès]

Hi Andrew,

We’re drifting away from the practical issue of adding a Redshift
service, but you raise interesting issues.

Andrew Tropin <andrew@trop.in> skribis:

[...]

>> Yes, that’s the usual tradeoff.  The choice made so far in Guix has been
>> to choose clarity over faithfulness to upstream’s name choices.
>>
>
> Maybe I'm wrong, but it's very likely that most of the users will be
> checking out upstream documentation anyway during configuration of some
> programs and those renamings will bring a lot of confusion and
> especially, when the record fields names will be combined with names in
> escape hatches.

I think there doesn’t have to be a single answer.  For Redshift and its
handful of options, I see little incentive to go look at ‘man redshift’;
it doesn’t add much to what we provide.

For more complex services, the answer might be different, although again
the Dovecot service shows that, even for this big a service, we can
provide comprehensive bindings and associated documentation.

[...]

>> I can see the appeal of alists, but the choice made in Guix is to use
>> records for configuration; that has advantages, such as type checking,
>> detection of incorrect field names, and the ability to use all the bells
>> and whistles of (guix records).
>
> Type checks are possible with data structure driven approach as well and
> in a fact it's much more flexible and powerful, however to be fair it
> will require some work to prepare a good framework for that like
> https://github.com/plumatic/schema
> or
> https://github.com/metosin/spec-tools/blob/master/docs/02_data_specs.md
> for Clojure.
>
> It's also possible to generate documentation for such specs.
>
> Potentially, such approach is more powerful.

I’m aware of Clojure specs, but I don’t find it convincing compared to
records, at least for our use case.

[...]

>>> It would be good to extend home-files-service-type with config-file
>>> generated above and home-profile-service-type with the value of
>>> `redshift` field.
>>
>> Regarding the former, that’s not something we usually do for system
>> services.
>
> Imagine terminal or almost any other user space program

I’m not imagining: we’re discussing a very concrete service here.  :-)

For Redshift, I don’t see the point of making the config available
globally.  For system services, there’s only a handful of exception (PAM
and OpenSSH come to mind, but see /etc).

Again, there doesn’t have to be a single answer.  I suspect many
services won’t need to make their config available under ~/.config, but
if some do, so be it.  I’d say that the default should be to not make
config available unless that’s required, just like what we do for system
services.

How does that sound?

>> As for the latter, I thought about it but I’m not sure what it would be
>> used for.  WDYT?
>>
>
> It can be used for debugging, for man pages or when redshift don't use
> shepherd service and started in different way (by wm for example).

The point of this Redshift service is to have it started automatically,
so to me the only reason to add ‘redshift’ to the user profile would be
to allow ‘man redshift’.

I don’t view it as super useful in this case, and would instead lean on
the side of not “polluting” the user’s profile, but I can very well
imagine that in other cases we’d prefer to extend the user’s profile.

>> I understand your concerns, but I think they’re beyond the scope of this
>> review.  I also think that there’s ample experience with system services
>> showing that writing “nice” configuration bindings actually works in
>> practice.
>
> I saw how well-written, but macros-based solutions in Clojure ecosystem
> slowly died and substituted with data-based.  I understand that Guile
> ecosystem has a slightly weaker toolkit for processing datastructures,
> but by the end of the day I think we will be here sooner or later.
> Using macros instead of datastructures feels for me like remaking the

Records are data structures, not macros.

> same mistake again knowing the consequences.  Maybe I'm wrong.

Maybe one of us is wrong, or maybe it’s more complex than this.  :-)

As it turns out, I find Guix’s configuration records rather nice to
use—much nicer than, for example, Gnus’ loose configuration trees.

Thanks for your feedback,
Ludo’.