From: Andrew Tropin <andrew@trop.in>
To: Julien Lepiller <julien@lepiller.eu>
Cc: Development of GNU Guix and the GNU System distribution
<guix-devel@gnu.org>
Subject: Re: guix home
Date: Fri, 19 Mar 2021 11:18:53 +0300 [thread overview]
Message-ID: <CABrWRW1BrqgkJfu9svdb80vbjnKNnJwCKuSReOtPMZmZ-NsZiA@mail.gmail.com> (raw)
In-Reply-To: <831CF304-5776-49F3-90E2-26D145C175F3@lepiller.eu>
Hi Julien, very glad to see you here!)
> Obviously I'm not a big fan of having configuration that can be modified
> after I ran guix home, but I understand this approach sounds less crazy
> :). I think both approaches have a lot more in common than they diverge,
> so merging one in guix is just one step away of merging the other :)
>
> Having a read-only home is a fun experiment (that have been going since
> I started guix-home-manager, so it's definitely possible), but a bit
> broken, and I keep poking holes for software I can't manage properly.
I really like the idea of strict separation of configuration and state,
and read-only home sounds like a rational solution to me, however it's
not a step in the right direction, but a leap, which not possible for
many even advanced users right now.
I considered many options like read-only home, read-only ~/.config and
few others, but decided that the transition to a new tool for most people
should be iterative and as smooth as possible. It will help to grow and
educate the community before exposing them to smart and great, but very
unusual approaches.
Thus, targeted symlinking is more a social decision rather than
technical. Configs itself remain immutable, but can be mixed with files
managed by user or other software.
> Also, I had this grand vision of using "extension points" in services,
> which might be useful to have in Guix. Though I never ended up using
> them in any meaningful way ^^'.
I have a small write-up on the topic [fn:1]. From time to time I feel
restricted by service extension mechanism, I know use cases where some
improvements to the mechanism will be beneficial, but for now I would
say they are statistically insignificant and can be workarounded with
other tools.
`guix home` propose the evolutionary approach here too, we stick with
what we have in guix system service extension mechanism, make a tool to
be a part of the guix, grow user base, collect use cases hard to solve
with current capabilities, make a decision based on collected data to
improve/modify extension mechanism, which affects both `guix system` and
`guix home`.
Otherwise, we can face a problem of integration gap, which won't be
solved in years.
> Merging either of our work will make it more visible and attract more
> users/contributors, that would be great! If we settle with Andrew's
> approach, I'd be glad to provide my own services, but I will also
> probably add something to get back my dear read-only home, because
> that's the intellectually superior approach, albeit broken ;)
As I said earlier I endorse and support all the good ideas and would like
to see them in `guix home`, keeping a space for users to allow them
making one small step at a time towards wonderful world of declarative
configurations, not giant leap)
Appreciate all your ideas and the work you did on the project, I learned
quite a lot from it!
* Footnotes
[fn:1] https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E
next prev parent reply other threads:[~2021-03-19 8:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 6:09 guix home Andrew Tropin
2021-03-14 15:46 ` Joshua Branson
2021-03-15 2:15 ` Ryan Prior
2021-03-16 8:23 ` Andrew Tropin
2021-03-15 16:51 ` Ludovic Courtès
2021-03-15 20:16 ` Julien Lepiller
2021-03-19 8:18 ` Andrew Tropin [this message]
2021-03-16 9:09 ` Andrew Tropin
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABrWRW1BrqgkJfu9svdb80vbjnKNnJwCKuSReOtPMZmZ-NsZiA@mail.gmail.com \
--to=andrew@trop.in \
--cc=guix-devel@gnu.org \
--cc=julien@lepiller.eu \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).