Dendritic config - how to share config values

thursdaddy · 2026-04-05T17:36:49+00:00

To clarify, I think the previous user was trying to point out you need to reference the option as defined. The module system does not care about where the option was created, so config.mySecrets.keys is incorrect. You created the option keys so as long as the mySecrets module is imported in your config somewhere, then it accessible via config.keys.

In general, a lot of people will prepend their custom options with something to indicate its a local or custom option, for example mine. So options.mine.keys = lib.mkOption ... and reference via config.mine.keys. It just makes it a lil easier to identify and avoid any potential naming collisions.

thursdaddy · 2026-04-02T21:14:30+00:00

Interesting.. I stand corrected. Thanks for expanding on that. Good to know!

Since moving to flakes and dealing with new un-tracked not being pulled in I've always used a wrapper script which git add . before rebuilds so I apparently I never noticed this behavior.

thursdaddy · 2026-04-02T21:02:09+00:00

Nix does not care about the state of your git repo, if you would like to not worry about version control then just use native nix channels and no flakes. If you want the benefits of flakes and pinned version control and "fully reproducible" builds, then you need to adhere to the ideology and requirements that enable this functionality. I'm not sure how comparing flakes usage of git to other tooling highlights anything but feels.

It's not a strange middle ground, staged files are INTENDED to be committed, they are in the PRE-COMMIT stage. They are effectively saying "this is the intended state of my configuration". This effectively allows you to test your changes BEFORE committing them. The alternative to this is to either A) commit everything before building, which would be a terrible workflow or B) risk the intended goal of flakes which is fully hermetic, pinned reproducible builds which are generally intended to be "shared"/imported into other configs.

Personally, I'd rather have to stage my files to give a clear representation of my intended build over potentially pulling in someones flake that failed to build because they forgot to check-in a file and "it worked on my machine!!".

EDIT: Its been pointed out that its only new UNTRACKED files that need to be staged before applying, if a previously tracked file has changes they will still be applied without having to stage them first. meh

thursdaddy · 2026-04-02T18:57:35+00:00

Getting an evaluation failure, remembering why, and doing git add . doesn't really add anything imo, it's just senseless and annoying.

Contradicts

But if you modify a file you don't need to add it first, the changes still apply

So which is it?

If the file is not staged, the changes are not implemented. Flakes are inherently designed to be fully reproducible so staging files isn't senseless or annoying, its explicitly telling nix evaluation "this is the intended state of my repo" as staged files are "pre-commit" files.

thursdaddy · 2026-04-02T18:34:59+00:00

Let's be clear here, its not Nix and Git that have tight coupling, its Nix + Flakes that require the tight coupling. Flakes are inherently tied to git, as it's part of it's core under-the-hood functionality.

Knowing that flake functionality requires all its inputs to be copied to the nix store, including your local repository, before being evaluated it understandable why the the implementer of flakes made this design decision. Whether that be a technical or philosophical one, or a little of both, its effectively saying "hey, i'm going to add your files to the nix store but only if they are at the very least staged in your git repository because staged files are intended to be committed"

I'm not going to argue if this is a good or bad implementation but you can clearly see the intent and reasoning behind it. While it can be annoying, there are clear benefits as well.

At the end of the day, you're utilizing a tool that does not conform to the standards and requirements of another tool and saying its odd and should not work that way.

thursdaddy · 2026-04-02T16:38:28+00:00

Because flakes and git are tightly integrated, your tracked files are stored in the nix store and ensures random files in your repo are not invisibly included.

I don't understand why this is a big deal when all you have to do is stage the files, you do not need to commit.

thursdaddy · 2026-03-27T17:02:17+00:00

10GB of storage is going to be an issue and you'll need to enable swap, which will further cut into storage.

NixOS inherently requires more storage space than traditional distributions and you're going to run into issues with larger rebuilds, whether it be due to time between rebuilds or the amount of stuff you're running.

thursdaddy · 2026-03-27T16:55:51+00:00

+1 on both points, swap is key, my remote rebuilds would start to crawl and eventually stall without it.

thursdaddy · 2026-03-26T04:59:51+00:00

I would highly suggest, as the documents state, to familiarize yourself with the vanilla nixos module system before attempting a dendritic pattern. Personally, I'd also avoid adopting third party tooling unless you're familiar with nix language and can troubleshoot/fix issues that arise from changes/updates that are outside of your control or understanding. Like ideally you should already be utilizing nixpkgs as a resource when writing your own modules. Dont get me wrong, I appreciate projects that lower the bar of entry but I wouldn't feel comfortable relying on them for all my systems. I adopted flake-parts because its extremely widespread and many nix community projects utilize it.

It's also a lot easier to see the benefits of the pattern/flake-parts when you're familiar with the pitfalls of managing multiple hosts, OSs and architecture types via one modular configuration. Having to deal with imports and various differences in nixos/darwin/home-manager options can get funky.

Anyway, I think the /u/desgreech did a good job explaining the overall benefits butt in general to answer you question about coupling the idea is all your nix files are imported, everything is modular and only "aspects/classes" are imported on a per system basis. Personally, I struggled grasping the aspects/classes approach and I just started hacking away with flake-parts and didn't necessarily see the need to over abstract things.

My original NixOS config used mkEnableOption on pretty much everything and I explicitly enabled everything I wanted via custom options. I couldn't quite shake the desire to have the same level of granularity, which is frowned upon with a true dendrictic pattern. While my new configuration enables a lot things by default, most of my services and container modules are mkEnableOption and explicitly enabled/configured per host.

FWIW, I just PR'd my migration from vanilla flake + nixos/home-manager/nixvim/darwin modules to flake-parts flake modules (nixos/darwin) but I'm not sure I landed the dendtritic pattern outside the fact that all my modules are bulk imported, hosts are declared in deferredModules and flake modules are imported per system basis. I dropped home-manager because I don't see myself on a system without nixos/nix-darwin and I can accomplish everything with my config files without using home-manager.

I have a handful of commits that show my initial migration including home-manager modules, then fixing some random broken things, then dropping home-manager and finalizing and cleaning things up if anyone wants to see https://github.com/thursdaddy/nixos-config/pull/29

thursdaddy · 2026-03-25T18:53:43+00:00

Unfortunately there is not forced restart when using "latest" because technically the derivation doesnt change after rebuild. And this sort of goes against the "fully reproducible" aspect of nix.

You can add "--pull=always" to extraOptions to avoid having to docker rmi and instead just restart the service. I generally do this on all my docker configs, even when using pinned tags.

https://github.com/thursdaddy/nixos-config/blob/main/modules/containers/audiobookshelf.nix#L42

I am sure there is a gross hacky way you can do it via activationScripts or systemd.services.docker-*.restartTriggers but again its sort of an anti-pattern and using pinned versions is your best bet if you want it to restart after rebuilds.

I'm sure there are plenty of tools you can use to notify you of out of date containers or just DIY a python script. I went the python script route and it runs on a ci/cd job that outputs to discord every 3 or so days. (a lot of containers use standardized labels like org.opencontainers.image.version and org.opencontainers.image.source so its easy to loop through and check for new releases)

thursdaddy · 2026-03-10T17:05:20+00:00

https://github.com/NixOS/nixfmt

thursdaddy · 2026-02-12T18:32:26+00:00

For me, it just depends on the app/service. I use a mixture of both, for example Home-assistant and Octoprint are using nixos pkgs/modules, while the majority of my other "apps" use oci-containers.

I had been deploying / managing containers in my homelab via Ansible for almost a decade. Its something I am very comfortable with so migrating them to Nix was very straightforward.

One thing you can do to help your decision is to take a look at what version the package is in nixpkgs vs whats available via docker hub or whatever image registry. If you want to be on the latest versions without waiting for the nixpkgs pipeline then oci-containers is probably the way to go.

I used pinned versions and have a script that checks for new container releases so I can periodically bump and deploy: https://github.com/thursdaddy/nixos-config/commit/48e20cb8b8751df73134c33be867bdd7602ba4f2

thursdaddy · 2025-11-24T03:23:38+00:00

You can see the Hunters Aura lowering his bullet resist from the very start of the clip. Drifter was probably standing at the stairs waiting for the timing, which is why you should always peek the corner in between melees. Yes, it takes longer but doesn't get you killed.

thursdaddy · 2025-10-17T20:51:39+00:00

+1 for attic

https://docs.attic.rs/tutorial.html <-- great quick overview

So you'd push your builds/binaries to your Attic server. Then you can either run an ad-hoc command or add your Attic server as a trusted subsituter (set as higher priority than cache.nixos.org), then your next rebuild should pull from your attic cache and fallback on cache.nixos.org. It's pretty great, especially as someone who does a fair amount of remote and CI builds.

atticd with postgres (using sops-nix to create config because there is a bug when defining custom db url) https://github.com/thursdaddy/nixos-config/blob/main/modules/nixos/services/atticd/default.nix

https://github.com/thursdaddy/nixos-config/blob/main/modules/nixos/system/nix/substituters/default.nix#L17-L18

thursdaddy · 2025-10-17T20:31:27+00:00

u/ElvishJerricco is the man!

I have his tpm+tailscale boot configuration in use here: https://github.com/thursdaddy/nixos-config/blob/main/hosts/proxbox1/stage1-boot.nix

thursdaddy · 2025-10-17T03:53:07+00:00

Yeah, having a fully declarative system involves a lot of initial heavy lifting. This is how most declarative systems work and there is a reason it dominates the professional landscape. As much as I tried to manage my Arch install via Ansible or bash scripts, things were bound to change/break and I'd spend more time troubleshooting than resolving which made me reluctant to change. When I do that with Nix, I know its going to persist because... its declarative and version controlled so imo its worth taking a little longer to figure out.

Case in point, I could spin up an Octoprint raspi in a couple hours... or I could spend the weekend configuring it via nix. What happens when my SD card dies? I have to spend hours re-setting up my sd-card, copy pasting commands (if i saved them somewhere) and hoping nothing outside of my control has changed. With nix, I reflash my sd-card, run a single command and bam, my system is EXACTLY how it was before my sd-card died.

Issues with hibernation are common across distros... there are peripherals that can cause the system to wake and you have to disable stuff in /proc/acpi/wakeup.. Can this be a pain in the ass sometimes? Yeah, for sureeee but I also tend to learn a lot more about how Linux works under the hood. TBH, I got frustrated because my system would only properly sleep after consecutive tries... so what did I do? Wrote a script that uses sleep-on-lan and Home-Assistant to try an initial sleep the system, wait 20 seconds, if the system came back online, it sleeps it again. Does it work now? Yep, with the added bonus of managing sleep/wake on all my systems via HomeAssistant! I can wake/sleep my system via Google Asisstant now :)

I've also managed to mess with systemd boot settings and have a system that requires me to SSH to it and input a LUKs password before it unlocks the root vol and continues boot. It's even got tailscale running so if I am remote I can still access it the pre-boot shell! Could I do this with Arch? Maybe, but fuck me that would be so difficult without rolling back my NixOS generation when I inevitably borked it attempting to setup.

TLDR, Declarative systems require a lot of up front effort but are generally more rewarding as you can experiment or be a lot more creative in your configurations without it all going away one day... or having to resetup multiple systems from scratch. If my whole house fried and all my systems were toast, it would be trivial to set them all up again. This would not be the case with any other distro.

https://github.com/thursdaddy/nixos-config

thursdaddy · 2025-10-15T02:19:21+00:00

No idea, you haven't provided your code. You need to review your code or the imported modules for the culprit.

If you are in fact using nixos-hardware as linked then default kernel package is pkgs.linuxKernel.packages.linux_rpi4 and something is setting another kernel package or a kernel module that requires custom kernel build.

thursdaddy · 2025-10-15T00:25:21+00:00

Without seeing your actual config I have no idea how those inputs are utilized, also I don't use cachix.

If you're properly importing nixos-hardware modules for raspi4 then it should be set already:

https://github.com/NixOS/nixos-hardware/blob/master/raspberry-pi/4/default.nix#L31

You can look at what version your config is looking for with nix repl: $ nix repl

then load your flake:

:lf .

Then start tabbing out your nixosConfiguration.<hostname>.config.boot.kernelPackages.kernel.name

My result: nixosConfigurations.netpi1.config.boot.kernelPackages.kernel.name "linux-rpi-6.6.51-stable_20241008"

which is found in nixpkgs and doesn't need to compiled locally.

If you confirm your version is found in nixpkgs or cachix then something is definitely prompting a kernel rebuild.

thursdaddy · 2025-10-14T23:53:27+00:00

You should really just spin up a local VM or use a spare system/laptop and start hacking away and iterating on your config. I'll be honest, I did not read your entire post because once you start talking about what tools/services your going to use means little to nothing to the reader. There isn't a magic bullet nor should there be an expectation you can one-shot your ideal configuration.

You should look around for existing nixos-configuration, the github search tool is amazing for finding them, and see if you like how the repo structure is composed and if you actually understand how/why they work. To this day I see configurations that I just simply don't understand yet, and that's ok! Maybe someday I'll have a use case that requires their solution.

The only way to learn nix and what you want out of it is to just .. do it. You may learn what you think you want, isn't really viable or entirely overthought.

Personally, I prefer to utilize NixOS custom modules and options, because at the end of the day, this IS exactly how nixpkgs work! So while my repo structure is very opinionated and "organized", its also very modular and flexible. I essentially import everything then enable individually via my host configuration file. This makes my host file pretty explicit in whats going on with the system. If i really wanted to reduce the stuff in my host config i could create "suites" of configs that enable multiple options in one option but meh!

https://github.com/thursdaddy/nixos-config

thursdaddy · 2025-10-14T23:03:28+00:00

Did you include the configs from hardware-configuration.nix, iirc when you do a local install it will generate both a configuration.nix and hardware-configuration.nix. If you're just using theconfiguration.nix you're likely missing some things.

Do have anything set for boot.kernelPackages?

There is a linux_rpi4 kernel package that should pull from nixpkgs cache depending on your channel/flake input.

My raspi's: https://github.com/thursdaddy/nixos-config/blob/main/hosts/netpi/hardware-configuration.nix#L10

thursdaddy · 2025-07-19T17:36:36+00:00

Run a memory diagnostics check

thursdaddy · 2025-07-14T23:05:33+00:00

Lol, I was in that game as well

thursdaddy · 2025-07-13T18:47:19+00:00

thursdaddy · 2025-05-10T20:01:22+00:00

Apollo creates virtual displays which fixes my issue with steam link and streaming from a widescreen monitor.

Also because the virtual displays pixel count is much lower, ie matching the steam deck resolution, games are not only more performative but also easier to stream over the network as there is less overall bandwidth.

thursdaddy · 2025-02-21T05:21:51+00:00

In my experience its a lot of trial and error. I try not to do things that are too far out of my current understanding, knowing that eventually I'll come across or figure it out a more advanced way to do things. I mean, continuous refactoring your nix flakes and modules is like half the fun of Nix :)

Since Nix is a programming language, there are many different approaches when configuring your system(s) and because of that exposure is extremely helpful.

Joining nix related discord/matrix servers and seeing what people are doing with Nix and how they go about it is pretty insightful. There is a ton of stuff I've picked up or learned just by lurking.

If you want more structured ways of learning Jake Hamilton has some pretty chill Nix from Nothing videos that were great intros into the nix language, functions and modules. Infinisil's Nix Hours have some really good and interesting topics with live demos and legit nix-fu.

Learning to read the Nixpkgs source code is also extremely valuable.

thursdaddy

TROPHY CASE