From: Xinglu Chen <public@yoctocell.xyz>
To: Andrew Tropin <andrew@trop.in>, ~abcdw/rde-devel@lists.sr.ht
Cc: Andrew Tropin <andrew@trop.in>
Subject: Re: Naming conventions
In-Reply-To: <878s4l8kai.fsf@trop.in>
References: <878s4l8kai.fsf@trop.in>
Date: Tue, 11 May 2021 17:29:54 +0200
Message-ID: <8735utgufh.fsf@yoctocell.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 11 2021, Andrew Tropin wrote:

>> The configuration record types, e.g. =E2=80=98home-gnupg-configuration=
=E2=80=99 don=E2=80=99t
>> necessarily have to be prefixed with =E2=80=98home-=E2=80=99.  One of th=
e things we
>> would like to avoid is code duplication with Guix proper,  if Guix
>> proper already has a =E2=80=98mcron-configuration=E2=80=99 record type, =
we would like to
>> be able to just reuse it instead of creating our own
>> =E2=80=98home-mcron-configuration=E2=80=99 record type.  It is the servi=
ce type that
>> actually controls how a record type is going to end up in the user=E2=80=
=99s
>> home environment/operating system.  I think it makes sense to drop the
>> =E2=80=98home-=E2=80=99 prefix from the configuration record types.
>
> I had this question near first days of Guix Home.  It's tempting to
> reuse already existing configuration record, but we won't do it:
>
> Sometimes we want to reuse it (shepherd-configuration), sometimes the
> service has very different purpose (or maybe same purpose, but slightly
> different fields, like additional xdg-flavor? flag) and we don't want to
> reuse, but want to create a new record type for that.  It means that at
> in some cases we will have home-A-configuration and A-configuration, in
> some cases only A-configuration and it will be very confusing for users,
> which configuration to use.

Good point.

> That's why I think we have to prefix all home configurations with
> home-, not sure about nested records, but they probably have to have
> prefix too.

Hmm, that seems to be the best way to keep things consistent.

>> Guix System already has a service for Getmail (gnu services getmail),
>> this could just as well be used in Guix Home, and we could just add a
>> =E2=80=98home-getmail-service-type=E2=80=99 and some helper functions to=
 make it put the
>> configuration in the correct place instead of having to re-write a
>> =E2=80=98home-getmail-configuration=E2=80=99 record type
>
> Sadly, we won't be able to reuse as much code as you think.  We have to
> change directory default value, which leads to creating a separate
> home-getmail-configuration.

Oh, yeah, I didn=E2=80=99t think about the default value for a field.

> Not sure that there is much sense to try to reuse nested records,
> maybe it is.

It could be nice, but won=E2=80=99t be possible if we also prefix them with
=E2=80=98home-=E2=80=99, as you mentioned above.

>> As a side-note: When merging with Guix proper, should we create a new
>> (gnu home-services) namespace or should we just put the services in the
>> (gnu services) namespace?  With the latter, we could for example just
>> add =E2=80=98home-mcron-service-type=E2=80=99 to (gnu services mcron) an=
d modify
>> =E2=80=98mcron-shepherd-services=E2=80=99 to use a different G-expressio=
n to start the
>> mcron daemon depending on if it is a system service or a user service.
>
> I don't think we should mix home-services with services.  It will
> complicate things for both developers and users, especially for users.

Would it tough?  If all the home services are prefixed with =E2=80=98home-=
=E2=80=99 it
would be pretty clear if a configuration was meant for Guix System or
Guix Home, wouldn=E2=80=99t it?

> In previous threads by escaping duplications I meant that we will be
> trying to keep only one version of service in most cases (system-service
> or home-service), if it's not possible maybe we will be able to share
> part of implementation between them, but this is secondary.

Yeah, it would be nice to be able to share at least parts of the
implementation of the system mcron service and the home mcron service.

> We can completely prevent duplication like that:
> https://search.nixos.org/options?channel=3D20.09&show=3Dprograms.chromium=
.enable&from=3D0&size=3D50&sort=3Drelevance&query=3Dchromium
> https://rycee.gitlab.io/home-manager/options.html#opt-programs.chromium.e=
nable

Yeah, I don=E2=80=99t see why anyone would configure Chromium system-wide
instead of per-user.

> Good question, Xinglu and great arguments!)  Made me rethink and clarify =
to
> myself some things.  Thank you)

You are welcome!  I think it was a good idea to write down my own
thoughts to get a better picture of everything.