2-AUG-2024

2335

I’m working on committing off a bunch of work, I solved the DNS issue without adding a second phase, it ultimately boiled down to needing to split and calculate each zone via the nixosConfigTree instead of using the nixosConfigurations directly.

I have an annoying reversal that happens when calculating the nixosConfigurations that results in the domain coming first – I haven’t fixed that yet but it’s so ugly I feel obligated to mention it in the log.

I refactored some of the deploy scripts but just is really not up to what I’m putting it through, I think. In particular the nix flake update logic is a bit of a mess and often runs a couple times. This isn’t a huge issue, but it burns time; I suppose moving development to a VM will help with that, but that would require I actually get that built, which isn’t as interesting as chasing infinite recursion bugs.

In any case, I’m getting toto updated tonight, which unblocks barge and puts me back to where I was with ereshkigal before cutting over. This whole process took about a month, but I think it was a good move, except that I truly hate dealing with multiple git repos like this. I’ve looked at using worktrees and they aren’t quite what I want.

Really what I want is a monorepo that isn’t a monorepo. I want each project to have an independent history, but I also want to be able to tie commits together across repos. Right now when I make an update in telperion, nothing coordinates it with laurelin. I can do this through flakes (make each flake track via the remote git repo, update to specific SHAs, then do everything the ‘intended’ way, as I understand it), but this, plainly, sucks. Iteration on a change becomes difficult when building it, and while it is very handy to create ‘canonical’ deployments of a suite of tools, it isn’t great for hacking on a lab, where purity isn’t as valuable. I still want to be able to track that compatibility information, but most of the time I want to do it outside of my actual IaC; and instead have my ‘monorepo’ actually just be a bunch of independent git trees in the same git database, but with an additional way to tie two commits together when they are ‘compatible’. Ideally also allowing that tie to be revoked if a later discovery shows they aren’t compatible.

The idea is still a little nascent, but I think this is doable in the context of git but with different semantics to the standard git repo.

In any case, I need another project like I need to increase my topological genus, so I’m just going to focus on standing up some services and getting btg sorted.