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?
Re: Useful Info related Emacs functions (was Re: more than 1,800 dependent packages: website out of date)
Hi, Cool! Thanks for sharing. On Wed, 18 Oct 2023 at 20:41, Matt wrote: >((string= info-file "guix") > (concat "https://guix.gnu.org/en/manual/devel/en/html_node/; > (if (string= node "Top") "" > (concat (replace-regexp-in-string " " "-" node t) > ".html" And this is easier than mine. :-) Cheers, simon
Re: Golang mudules to follow common grouping
Hi, I've accidentally included other patch to this series. I've re-sent it under the new issue number https://issues.guix.gnu.org/66627. Thanks, Oleg On Mon, 16 Oct 2023 at 19:17, Sharlatan Hellseher wrote: > > Hi, > > I'm about to create golang-check and golang-build modules, which both are > core and would be in used by others. As Maxim mentioned, the most time > consumption task would be migrating copyrights header properly. > > On Sun, 15 Oct 2023, 22:25 Wilko Meyer, wrote: >> >> >> Hi, >> >> Sharlatan Hellseher writes: >> >> > I think it's time to split (gnu packages golang) into some logical groups, >> > see >> > Python, Lisp for example. >> > >> > Thoughts? >> >> IMHO this sounds like a good idea as it would improve the >> maintainability of golang packages in the long run. We have 487 package >> definitions right now: >> >> (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm >> 487 >> >> which already seems quite laborous to split into logical groups (while >> getting the copyright information right as well and maintaining the >> gitlog history etc.); so it probably classifies as a task that should be >> tackled sooner than later as it'll cause more work over time the more >> golang packages exist. >> >> -- >> Kind regards, >> >> Wilko Meyer >> w...@wmeyer.eu -- … наш разум - превосходная объяснительная машина которая способна найти смысл почти в чем угодно, истолковать любой феномен, но совершенно не в состоянии принять мысль о непредсказуемости.
