I’d like to use NixOS without having to commit shell.nix files to my team’s projects (so I don’t have to sell them on NixOS just yet). I’ve come up with a way of doing it, but I’m curious what other nixers have come up with.
I create a separate “nix” branch where I commit shell.nix and any supporting files, including a script that bootstraps the relevant files on a “fresh” (not yet nixified) repo.
The bootstrap process is run from your project root, and involves cloning the nix branch to a temporary directory, running the bootstrap script it contains, and removing the temporary clone.
The init script itself ensures shell.nix and its supporting files will be ignored (using .git/info/exclude), then uses git cherry-pick and reset to copy the relevant files to the repo.
This is a little complex, but it’s worked well so far. The downside is that any time I switch to the nix branch then back to a different branch, my nix files disappear and I need to bootstrap them again. This only occurs if the branch switching involves the nix branch, and it’s due to the way I’m ignoring files. The upside is that it’s forced me to maintain a reliable bootstrap script.
This gist shows how I set up the nix branch in the first place, and this commit shows the full details (for an example Rails app).
I’d like to hear what approaches other nixers have taken, and what’s worked well.
Instead of jumping through hoops, I would prepare a pull request that adds a few required lines to .gitignore as well as a .envrc and your shell.nix. There are no downsides or side-effects from this so selling the idea to your manager should be straight forward.
I’ve done this before, the only extra thing I’d recommend is to make shell.nix and nix/ (or wherever you call your support directory) a symlink to some place outside your workspace. That way if you do a git clean -fdx (to clean up cached compilation results, for example), you’ll only delete your symlinks instead of your hard work. I learned that lesson the hard way
If your colleagues are pedantic about not adding unnecessary cruft to ignore files, you can instead put them in ~/.gitignore and add this to your ~/.gitconfig:
[core]
excludesfile = ~/.gitignore
(the downside is if you do want to add nix files to some repos, you’ll probably forget because they’re ignored)
That’s a great idea, I totally overlooked the symlink approach in this case. I’m actually going to submit a PR to add the nix support files to the current project, but I’ll probably use your suggestion for future projects while I get the nix details sorted out. Thanks!
Related to this, I’ve been working on a little go tool: go get github.com/nyarly/git-along
Use is something like:
git branch nixsupport
git config --bool branch.nixsupport.configstash true
git along add nixsupport shell.nix
git along add nixsupport .envrc
git push origin nixsupport
<edit>
git along store nixsupport
git along retrieve nixsupport
git-along acts like a specialized porcelain, so it ignores git’s normal rules (e.g. .gitignore), and you’re safe to stash things there. There’s still a little bit of finagling regarding managing the remote for a stash branch, (as well as the open question of naming that concept better…) and maybe automating e.g. .git/info/exclude based on the stash branch contents. But all in all, it works well for what it’s supposed to do: allow for the control of idiosyncratic project config files.
