I have a js proxy project that auto-persists changes out live, as you change the object, rathre like this. I really need to get back to it.
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.
- 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.
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.
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.
It's amusing that nixpkgs contributors have spent thousands of human-hours to craft a module system suitable for patching and wrapping any piece of software to accept static configuration, but NixOS, home-manager, and now json2dir end up producing an activation script which litters the filesystem with said configuration.
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.
I don't think json is the right language for this. You can't really have comments, and your scripts have to be in a single line (because json doesn't support multi-line strings).
9 comments
[ 0.21 ms ] story [ 25.4 ms ] threadThe 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.
- 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.
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.
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.