I'm kinda of the opinion that the real option to handle dotfiles is to override/overlay the package itself with the dotfiles, patching if necessary in order to make it look to the dotfile inside the store, so you can copy the closure of *your* whole app to any machine even if they don't use/can't use nix tho.
Everything runs just so much better if the binaries in your profile are wrapper scripts that essentially run "program --config /nix/store/<hash>-program.config". Each file that needs to be copied or symlinked to a "blessed" location in the global mount namespace via an activation script is a failure opportunity, which breaks the atomicity of profile activation and leaves you (or some complicated logic in NixOS/home-manager) to clean up the mess.
Even in the case that a program cannot be patched to run this way, it is easy these days to bind-mount into a clean namespace via bwrap or similar. Alas, shared libraries are kind of the Achilles' heel of this approach.
NixOS is directionally the future but the implementation is self-crippled by ideology in a few important places. There is absolutely no reason why `buildFHSEnv` couldn't come by default rather than `/sw/` or `/run`: links into the store are links into the store, putting them in a place that breaks everything? That's incompatible by design and you know it's intentional because symlinks are cheap you could just do both!
Ditto `nix-ld` being necessary, it's a great piece of work but the dynamic linker should be in the normal place and know about all the libraries on the system by default. It's possible to do this in my NixOS modules? `uv add flash-attention-blah`? Works without any trouble on my machine. But it was a super pain to set up that most people won't put up with.
`home-manager` is awesome, it pioneered a bunch of great stuff, but it's not maintained with the vigor it once was, and some dated ideas got wired in really deep. I still run it, and I probably will forever because it slays at some stuff, but that's the nice thing about symlinking into a a store! I can use it where it works well, and use other stuff where it's trouble. This is the magic of NixOS. The next thing I'm trying is https://github.com/outfoxxed/impurity.nix, which comes highly recommended by heavy Nix people I know.
I think it's time to just update NixOS to run things properly by default. It can be done with zero sacrifice on real pure builds and caching/substitors working properly and all of that. I sometimes call Nix "advanced alien technology that was badly damaged on crash re-entry". @jade is a boss and says kind of the same thing a different way.
But again, the beauty of NixOS is that you can do this yourself, an overlay is a pure function from the world as it is to the world as it ought to be.
EDIT: I know talk is cheap and code wins arguments, and I know this is about a year overdue and not released yet, but it's got beta testers now, it's coming: https://gist.github.com/b7r6/721f62d6431c77b64592a55706d87fd...
jauntywundrkind•2h ago
The advantage of being able to see state easily is incredible. It's so scriptable. I only demo'ed it for myself, but I've also run a git-auto-commit program on the data as it changes over time, which is much more useful commits to look at over time than seeing data in a huge JSON file change.
I really really hope we can start using the hierarchical file system to hold data. For transport, its convenient to have data glommed together, but I think we're really missing out on end user programming and malleable systems by having these rich data formats everywhere and keeping the filesystem dumb.
QuantumNomad_•2h ago
- OP project manages contents of multiple files as a single JSON with the intention of tracking that one single file in git, and splits it into the original files when you apply it
- Your tool sounds like it can do the same thing, split one JSON file into multiple files, but it’s geared for use the other way around, to track in git as separate files the pieces that make up the total JSON as a.
Both tools can probably be used for the same, it’s up to the user to decide if the combined file is the result and the split files are for git or the other way around.
And fwiw, I agree with you that keeping the split up thing in git is more helpful for reading diffs than a single massive JSON file. I have some scripts in one of my projects too, that takes fragments split across multiple files which are separately tracked, and combine those into single JSON files when I use them.
alurm•2h ago
Edit: I have updated the documentation to mention this explicitly, thanks!
porridgeraisin•2h ago
My bespoke clipboard manager also uses the filesystem as the primary data structure.
h/$serial_number/$mime_type/{data, index}
H for history. data has the actual paste data. index has metadata useful for search - window name, day name, I also include wifi network so I can find clipboard history in terms of place, if I remember it that way. It also includes a copy of the data file if it's a text paste. You can include anything really it's fairly flexible. You can write whatever executable you want to the *-posthook file and they are all executed with argv having the path to the history entry directory. You can then modify the index as you please.
I have a few frontends to actually use this clipboard history as well. One is a gtk3 frontend searchbar + list below. Another is a cli fzf based thing.
Since the data structure is just the filesystem it's really composable and amazing.
Various things like blacklisting windows, "pausing" clipboard history, etc are all just files as well.
If you create a pause file it will pause (there's an if test -f pause check). You can add a grep -E pattern to the blacklist file and it won't paste from those window names.
Unlimited history since I don't care about space. But it does support wrapping around after N items.
Sync with phones is one thing i have to figure out...syncing across my different computers is dead easy of course.
alurm•2h ago