Re-evaluating the practice of automating user configuration

Re-evaluating the practice of automating user configuration

[Liliana Marie Prikler]

Hi Guix,

as we all are more or less aware of, Guix automates quite much of the
user's configuration for comfortably hacking on our codebase.  As has
been argued elsewhere, both by myself and fellow Guix, this is not
always a good thing.

Let's start with the cleanest example of how to do things the right
way: Our Emacs configuration is split across two files (one of which is
a directory, but let's get back to that).  One of them are the
directory-local variables stored in .dir-locals.el, the other the
snippets in etc/snippets–if you're using YASnippet, the former loads
the latter.  I have no qualms with this being automated, as Emacs
itself gives me plenty opportunity of opting out of it.  I could
declare any of the included variables or forms unsafe and ignore them
in future sessions.  Likewise, I can mark them as safe to affirm my
consent that these variables be changed in /path/to/guix/checkout.

None of this holds for the git config, which we install unasked in the
working tree with a DATA target that we want neither distributed nor
installed otherwise.  This has led to confusion both in the mailing
lists and the IRC on multiple occasions, so I'd propose we instead use
PHONY targets for:
1. git-hooks to install the git hooks that committers need.
2. git-config to install all of the git config
  a. git-config-diff to just install the diff xfuncs
  b. git-config-format to just install the format block
  c. git-config-pull to just install the pull block
  d. git-config-sendemail to just install the sendemail block
3. git-fullconfig for both 1 and 2.

Internally, these would still be based on the actual file names to get
time-stamps to work.  Thus, on a fresh pull or if you haven't pulled in
a while, you can run either `git fullconfig` or any of the above to set
things up.

Incidentally, my .git/config currently reads the following:

[include]
	path = ../etc/git/gitconfig
	path = ../etc/git/gitconfig
	path = ../etc/git/gitconfig
	path = ../etc/git/gitconfig

So clearly, automatically hooking up these configurations could be done
more cleanly :)

WDYT?

Re: Re-evaluating the practice of automating user configuration

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 2896 bytes --]

On 2023-10-19 16:36:32 +0200, Liliana Marie Prikler wrote:
> Hi Guix,
> 
> as we all are more or less aware of, Guix automates quite much of the
> user's configuration for comfortably hacking on our codebase.  As has
> been argued elsewhere, both by myself and fellow Guix, this is not
> always a good thing.
> 
> Let's start with the cleanest example of how to do things the right
> way: Our Emacs configuration is split across two files (one of which is
> a directory, but let's get back to that).  One of them are the
> directory-local variables stored in .dir-locals.el, the other the
> snippets in etc/snippets–if you're using YASnippet, the former loads
> the latter.  I have no qualms with this being automated, as Emacs
> itself gives me plenty opportunity of opting out of it.  I could
> declare any of the included variables or forms unsafe and ignore them
> in future sessions.  Likewise, I can mark them as safe to affirm my
> consent that these variables be changed in /path/to/guix/checkout.
> 
> None of this holds for the git config, which we install unasked in the
> working tree with a DATA target that we want neither distributed nor
> installed otherwise.  This has led to confusion both in the mailing
> lists and the IRC on multiple occasions, so I'd propose we instead use
> PHONY targets for:
> 1. git-hooks to install the git hooks that committers need.
> 2. git-config to install all of the git config
>   a. git-config-diff to just install the diff xfuncs
>   b. git-config-format to just install the format block
>   c. git-config-pull to just install the pull block
>   d. git-config-sendemail to just install the sendemail block
> 3. git-fullconfig for both 1 and 2.
> 
> Internally, these would still be based on the actual file names to get
> time-stamps to work.  Thus, on a fresh pull or if you haven't pulled in
> a while, you can run either `git fullconfig` or any of the above to set
> things up.
> 
> Incidentally, my .git/config currently reads the following:
> 
> [include]
> 	path = ../etc/git/gitconfig
> 	path = ../etc/git/gitconfig
> 	path = ../etc/git/gitconfig
> 	path = ../etc/git/gitconfig
> 
> So clearly, automatically hooking up these configurations could be done
> more cleanly :)
> 
> WDYT?
>

I have to admit I was surprised, and not in a pleasant way.  When I started
playing with Guix, I went over the etc/git/gitconfig and copied the parts I
liked into the .git/config.  For some reason I do not like tools automatically
touching the .git directory, and now I have the include there (5 times).

I think turning it into a manual step, with the granularity proposed above, is a
good and welcomed solution.  At least in my opinion.

Have a nice day,
Tomas Volf

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Re-evaluating the practice of automating user configuration

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Hi Guix,
>
> as we all are more or less aware of, Guix automates quite much of the
> user's configuration for comfortably hacking on our codebase.  As has
> been argued elsewhere, both by myself and fellow Guix, this is not
> always a good thing.
>
> Let's start with the cleanest example of how to do things the right
> way: Our Emacs configuration is split across two files (one of which is
> a directory, but let's get back to that).  One of them are the
> directory-local variables stored in .dir-locals.el, the other the
> snippets in etc/snippets–if you're using YASnippet, the former loads
> the latter.  I have no qualms with this being automated, as Emacs
> itself gives me plenty opportunity of opting out of it.  I could
> declare any of the included variables or forms unsafe and ignore them
> in future sessions.  Likewise, I can mark them as safe to affirm my
> consent that these variables be changed in /path/to/guix/checkout.
>
> None of this holds for the git config, which we install unasked in the
> working tree with a DATA target that we want neither distributed nor
> installed otherwise.  This has led to confusion both in the mailing
> lists and the IRC on multiple occasions, so I'd propose we instead use
> PHONY targets for:
> 1. git-hooks to install the git hooks that committers need.
> 2. git-config to install all of the git config
>   a. git-config-diff to just install the diff xfuncs
>   b. git-config-format to just install the format block
>   c. git-config-pull to just install the pull block
>   d. git-config-sendemail to just install the sendemail block
> 3. git-fullconfig for both 1 and 2.

As argued before, going this route would have the following downsides:

1. the pre-push-hook would no longer be installed out of the box, which
could mean forgotting to sign a commit and having to ask Savannah folks
to drop the offending commit(s).  That's a blocker for me, at least
until we have a server-side hook that can guard against this.

2. The pre-push-hook could go stale (not self-updating).  That's likely
to happen as people would seldom run 'make git-hooks' to refresh them.

3. We'd loose some notifications for teams, likely for first submissions
from users that have yet to run 'make git-hooks', or from users who
chose not too.

4. We'd have more problems applying patches since the 'useAutoBase =
true' is not enabled by default, and documentation is a weak assurance
that users will do this.

> Internally, these would still be based on the actual file names to get
> time-stamps to work.  Thus, on a fresh pull or if you haven't pulled in
> a while, you can run either `git fullconfig` or any of the above to set
> things up.
>
> Incidentally, my .git/config currently reads the following:
>
> [include]
> 	path = ../etc/git/gitconfig
> 	path = ../etc/git/gitconfig
> 	path = ../etc/git/gitconfig
> 	path = ../etc/git/gitconfig

That should be fixed in Git.  'git config --add include.path
../etc/git/gitconfig' should not be re-adding the same entries over and
over if they are already there.

All in all, I guess my position is unchanged: despite the potential for
surprises, automating and enforcing these configs provide benefits that
outweigh the cons, in my experience/opinion.

-- 
Thanks,
Maxim

Re: Re-evaluating the practice of automating user configuration

[Maxim Cournoyer]

Hello,

Tomas Volf <wolf@wolfsden.cz> writes:

[...]

> I have to admit I was surprised, and not in a pleasant way.  When I started
> playing with Guix, I went over the etc/git/gitconfig and copied the parts I
> liked into the .git/config.  For some reason I do not like tools automatically
> touching the .git directory, and now I have the include there (5 times).

I think it's mostly surprising because Git itself doesn't provide for a
way to provision sane per-project settings, which is what the build
system of Guix does.

-- 
Thanks,
Maxim

Re: Re-evaluating the practice of automating user configuration

[Ricardo Wurmus]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> All in all, I guess my position is unchanged: despite the potential for
> surprises, automating and enforcing these configs provide benefits that
> outweigh the cons, in my experience/opinion.

I concur.

In light of efforts to reduce cognitive overhead, I think it is a good
idea to automatically use the default configuration.  Contributors can
opt out, but I prefer not to have to think about yet another important
piece of configuration here.

-- 
Ricardo

Re: Re-evaluating the practice of automating user configuration

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On 2023-10-21 17:32:13 +0200, Ricardo Wurmus wrote:
> 
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> 
> > All in all, I guess my position is unchanged: despite the potential for
> > surprises, automating and enforcing these configs provide benefits that
> > outweigh the cons, in my experience/opinion.
> 
> I concur.
> 
> In light of efforts to reduce cognitive overhead, I think it is a good
> idea to automatically use the default configuration.  Contributors can
> opt out,

How can I do that?

> but I prefer not to have to think about yet another important
> piece of configuration here.
> 
> -- 
> Ricardo
> 

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]