Re: Re-evaluating the practice of automating user configuration
On 2023-10-21 17:32:13 +0200, Ricardo Wurmus wrote: > > Maxim Cournoyer 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. signature.asc Description: PGP signature
Re: Re-evaluating the practice of automating user configuration
Maxim Cournoyer 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
Hello, Tomas Volf 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
Hi Liliana, Liliana Marie Prikler 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
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. signature.asc Description: PGP signature
Re-evaluating the practice of automating user configuration
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?
