I do something similar, albeit a bit more bare-bones. I keep my dotfiles in a dotfiles folder that is a git repo and then just have a simple script to symlink everything. I have a couple of submodules in there (zplug, pyenv) and a bash script to keep them up to date, and then a few self managed binaries, like fnm. That's about it. I don't bother trying to manage anything outside of home or deal with secret values by…
Chezmoi[1] has been working well for me recently, replacing a set of Stow-able directories in a simple Git repo.
I haven't started using templates and things, for now it's just environment variables.
At our startup (FluxNinja), we provide MacBooks and Linux Desktops (System76) to our engineering staff. We have invested in common dotfiles[0] to help them keep dev experience consistent across machines. We use chezmoi for dotfiles management. Really recommend investing in common dotfiles at the organization level. For young developers, a standard setup provides a big productivity boost. [0] https://github.com/fluxni…
Is the usage of these standard dotfiles required for all developers? Personally I would always prefer to use my own dotfiles at work
Nix is like sailing from Oakland to San Francisco on an aircraft carrier for your daily commute. Most stuff I care about factors out into .config which I turn into a git repo, push to GitHub and slap on a CI checks for secrets. Most engineers don’t need to forge a demonic pact with the Nix gods who demand I upend and replace everything from my operating system to my wife.
95% of the time if I'm making nix a dependency it's just to install the correct version of python and poetry, then I let poetry handle the other dependencies. So it's totally possible to just use nix a little. My coworkers haven't even noticed the flake.nix in our repo, they just install those things by hand. But then there's that 5% case where you do have to forge a demonic pact with the nix gods, and it's handy to…
I had problems installing python dependencies with compiled library dependencies this way, eg pandas. Does that generally work for you?
I'm curious about, specifically, which files you (and the sibling commenter) want to manage outside of the home directory. Is it OS package-manager configs? This is highly dependent on distro, but for any use-cases where editing /etc/ is the recommendation, I have found that either: (a) It's a development environment thing (e.g. httpd vhosts) & thus I see it as quite separate to "my dotfiles" (a personal machine env…
On macOS I often have the need to place stuff in /Library.
What kind of stuff? I'm genuinely curious, as I've never once had to touch /Library manually.
Honestly, it really is not the language that’s the problem. While there are a few cases where it can trip you up at first, you wouldn’t be singing package descriptors even if it were Python — it simply has a business domain which is non-trivial. This non-triviality and organic growth show on the standard library of nix packages, but I fail to see how a lisp language or whatever be immune to it, besides having learned…
Nix is building a package manager AND a programming language. Guix is building a package manager only. It's a resourcing thing.
And one might even argue the opposite, a DSL made for creating packages may well be better. Especially that plenty of package descriptions are basically reads like JSON.
I have a similar system: I manage my dot files and a bunch of other configs by placing a git repository in my operating system's root directory, i.e. file:///.git. I use a .gitignore file to exclude most things from consideration while adding things to git. Transferring to another OS is as simple as copying the .git dir over.
Before your comment I never considered the inverse of .gitignore but apparently it’s very easy to do! https://stackoverflow.com/questions/987142/make-gitignore-ig...
This is cool, but I actually place ignored paths into the gitignore manually. This way I will always see reminders when a new file needs to be tracked or ignored. Otherwise I would forget to track new config files. E.g. when a new program is installed, its binary will be ignored by a previous rule added to gitignore (/use/bin/*), but its newly created config files in /etc will come up red when I run `git status`.
For me the killer feature of home-manager versus other dotfiles managers is that it also installs any software your dotfiles depend on or assume to be present on the machine.
To me it is marking what is “garbage” vs what isn’t in the .config folder. I like to experiment on linux a lot, like switching to plasma and back to Gnome and it always leaves like 20 mostly-empty folders trashed. I can then just remove the folder and go on my way with home-manager.
If you're running NixOS there's an impermanence plugin that allows you to specify specific directories and files you need to persist outside of what NixOs/HM builds for you and then use a tmpfs in-memory partition for root and/or home. Then at boot you're loading up the NixOS/HM config and then the persistent files are symlinked or mounted to where they need to be, but otherwise you have a fresh system on each reboot. It's a bit painful and manual to figure out exactly what to keep (unless you just want to keep the entire .config, for instance, which I don't) but it's amazing to know that you can mess up your home directory as much as you want and then it'll automatically clean itself with a reboot.
The biggest pain point I have with dotfile management is that none of my computers are exactly the same, so if I start pulling dotfiles from a repo I get unwanted configuration on a machine. It could be something as simple as a Vim theme not looking right on another computer because it's using a different terminal.
I guess what I should be doing is adding if statements into all of my config files, but instead I wind up just copy/pasting the parts of config that I like from my github repo and never actually doing real dotfile management. Which just leads to the repo becoming stale.