all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: guix-devel@gnu.org
Subject: Re-evaluating the practice of automating user configuration
Date: Thu, 19 Oct 2023 16:36:32 +0200	[thread overview]
Message-ID: <15a91f7c5fb5fce23d0863548f8a1ab39d91cb69.camel@gmail.com> (raw)

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?


             reply	other threads:[~2023-10-19 14:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 14:36 Liliana Marie Prikler [this message]
2023-10-19 15:04 ` Re-evaluating the practice of automating user configuration Tomas Volf
2023-10-21 14:46   ` Maxim Cournoyer
2023-10-21 14:45 ` Maxim Cournoyer
2023-10-21 15:32   ` Ricardo Wurmus
2023-10-21 23:44     ` Tomas Volf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15a91f7c5fb5fce23d0863548f8a1ab39d91cb69.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.