declare & apply via Nix #105
Conversation
nathanshelly
added
enhancement
infra
introduction
nathanshelly
force-pushed
the
nix-darwin
branch
from
335249d to
4905294
Compare
| @@ -0,0 +1,102 @@ | |||
| # nix | |||
There was a problem hiding this comment.
Hot take: all READMEs should be wrapped at 80 characters
There was a problem hiding this comment.
I think it makes it easier to read, and doesn't rely on the reader's editor doing soft-wraps
There was a problem hiding this comment.
this idea is growing on me, not yet ready to dive in that way
|
|
||
| ## how it works at a high-level | ||
|
|
||
| In practice a configuration boils down to putting files in expected locations. For example, `zsh` will respect any configuration in a `$HOME/.zshrc` file (and others like `/etc/zshrc`, `$HOME/.zshenv`, etc.). These files may be read directly by the program or they may set features of an environment (like environment variables or shell aliases) that apply to the tool when run in that environment. Even the act of installing a package in the end just comes down to putting the corresponding binary in a folder on your `$PATH`. |
There was a problem hiding this comment.
topic sentence here should be about Nix, not the problem Nix solves
|
|
||
| The complexity of a dotfiles configuration comes primarily from the sheer variety of files/expected locations and the occasional need to interface with a third party tool to move a given file to its corresponding location. For example, to install a given package one needs to interface with a package manager (`apt`, `yum`, `brew`, etc.). | ||
|
|
||
| Nix tooling abstracts this complexity away by providing a consistent interface to declare a wider range of config than any other tool I'm aware of. This varies from the least abstract symlinking of arbitrary files to setting high-level keys in a corresponding module which Nix tooling realizes by writing the corresponding files. |
There was a problem hiding this comment.
i do not understand what the second sentence means
|
|
||
| Nix tooling abstracts this complexity away by providing a consistent interface to declare a wider range of config than any other tool I'm aware of. This varies from the least abstract symlinking of arbitrary files to setting high-level keys in a corresponding module which Nix tooling realizes by writing the corresponding files. | ||
|
|
||
| In the high-level key case the Nix ecosystem has created a wrapper around a bit of config that makes declaring it as simple as setting the value of a specific key. For example, this [`system.defaults.NSGlobalDomain._HIHideMenuBar`](TODO: fill this) key controls whether or not the macOS menu bar is hidden. This [`users.users.nathan.packages`](TODO: fill this) key specifies the set of packages available to the `nathan` user. Nix tooling performs the actions required to apply this config: writing files, installing a package, flipping a macOS setting, etc. |
There was a problem hiding this comment.
this is not very high-level - i'm already kinda lost - and would be more lost if i didn't know kinda how Nix worked already. need a simpler example, or even no example - just tell me that Nix lets me set all my config in one place, in one way
There was a problem hiding this comment.
and that it has plugins or packages or whatever that let you set config for stuff that you normally can't automate, like macOS settings
|
|
||
| In the high-level key case the Nix ecosystem has created a wrapper around a bit of config that makes declaring it as simple as setting the value of a specific key. For example, this [`system.defaults.NSGlobalDomain._HIHideMenuBar`](TODO: fill this) key controls whether or not the macOS menu bar is hidden. This [`users.users.nathan.packages`](TODO: fill this) key specifies the set of packages available to the `nathan` user. Nix tooling performs the actions required to apply this config: writing files, installing a package, flipping a macOS setting, etc. | ||
|
|
||
| In other situations it may make more sense to declare a bit of config in its own file. To apply this config the file needs to be moved to the expected location for it. For example, [this key](TODO: fill this) causes Nix to apply the [`tmux.conf`](../tmux/tmux.conf) config in these dotfiles by moving it to `~/.tmux.conf`. |
There was a problem hiding this comment.
"this key" means nothing to me because i have not yet been introduced to a Nix config.
There was a problem hiding this comment.
also, who is the intended audience here? if it's a dev who is interested in this stuff, i recommend assuming they know how "config at large" works, since so far most of the content here has been explaining how config works (flags, files, etc)
There was a problem hiding this comment.
that'd let you cut a lot of the preamble, and get straight to what i'm here for: what is Nix and why do I care?
|
|
||
| In other situations it may make more sense to declare a bit of config in its own file. To apply this config the file needs to be moved to the expected location for it. For example, [this key](TODO: fill this) causes Nix to apply the [`tmux.conf`](../tmux/tmux.conf) config in these dotfiles by moving it to `~/.tmux.conf`. | ||
|
|
||
| > Arbitrary config code can also be inlined in `.nix` files via the """...""" syntax. See [here](TODO: fill this) for example. Nix tooling will then write this config into a file in the expected location for the corresponding tool. |
There was a problem hiding this comment.
again, not very high-level. almost like you're kinda assembling an "FAQ" or "samples" section?
nix/README.md
Outdated
|
|
||
| ## Nix ecosystem | ||
|
|
||
| The Nix umbrella includes multiple projects that when combined approach this goal better than any other system I am currently aware of. |
There was a problem hiding this comment.
already said "any other system I am currently aware of", repetitive here.
honestly, am down to cut it entirely - not sure it adds much beyond "i am shook this is good"
|
|
||
| These projects are: | ||
|
|
||
| - the Nix language tuned specifically for declarative, replicable configuration |
There was a problem hiding this comment.
"tuned specifically..." not needed in an "intro". if important, put after a colon
|
|
||
| - the Nix language tuned specifically for declarative, replicable configuration | ||
| - the Nixpkgs package manager | ||
| - Home Manager - a tool for managing the user environment (shell, editor, CLI tools, etc.) |
There was a problem hiding this comment.
"tool"? Nix-specific tool? Plugin? it's not standalone, right? or is it?
| - the Nixpkgs package manager | ||
| - Home Manager - a tool for managing the user environment (shell, editor, CLI tools, etc.) | ||
| - OS-specific tooling | ||
| - NixOS - an operating system built completely atop Nix thus supporting perfectly replicable, declarative configuration |
There was a problem hiding this comment.
are you going to use NixOS later? only mention if it'll be relevant i think
There was a problem hiding this comment.
also "perfectly" is flowery - recommend against too flowery language (this is a readme vs. a sales pitch lol)
nathanshelly
force-pushed
the
nix-darwin
branch
6 times, most recently
from
4a33a91 to
426031a
Compare
nathanshelly
force-pushed
the
nix-darwin
branch
2 times, most recently
from
5dc1a1f to
b085578
Compare
nathanshelly
force-pushed
the
nix-darwin
branch
3 times, most recently
from
e71df5f to
397ba08
Compare
nathanshelly
force-pushed
the
nix-darwin
branch
from
8d366b4 to
d54a513
Compare
|
closing in favor of #111. will incorporate feedback here in that PR |
TODO
related issues that can be cleaned up
sshconfig via Nix #101