Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

github.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

#11

Post by dietr1ch »

benreesman wrote: post #10
tadfisher wrote: post #8

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 esse…

This is a legitimately hard problem (as an `emacs` user on NixOS I see both sides of it and their merits). 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 ? T…

> 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.

Isn't that part of the point of having NixOS? Dynamic linking into whatever seems best from the nix-store sounds handy until you realise it's just going back to a regular mutable distro where the state is whatever and build instructions start looking like "install all these libraries and cross your fingers just in case" and "works on my machine"™ reigns.

Re: Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

#13

Post by benreesman »

dietr1ch wrote: post #11
benreesman wrote: post #10

Earlier quoted context omitted.

This is a legitimately hard problem (as an `emacs` user on NixOS I see both sides of it and their merits). 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 ? T…

> 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. Isn't that part of the point of having NixOS? Dynamic linking into whatever seems best from the nix-store sounds handy until you realise it's just going back to a regular mutable distro where the state is whatever and build instructions start look…

There's a range of options on this and numerous good mental models for it: flakes are "dirty", Haskell does things in a very granular regime of mutability bounded context combinators, NixOS has to cope with changing hardware (NixOS modules at the absolute apex of "official"-ness escape hatch it, you have to be pretty explicit to get a reliable pin of the kernel, I'm running `linuxPackages_testing` on this machine I'm typing from because I'm setting up a 5090 and need "the newest one" on everything: 2 months ago? 6.16-rc3, today: I think it's 6.17-rc1 or something, haven't looked).

So, much like a `nix flake check` might fail and you want your CI to flag that, a `nh home switch .` might be necessary to get the editor you need to fix the fail. Functional programming has decades of consensus on every possible variation of this.

There are any number of things you could do here (and the message linking you to the `nix-ld` website is an improvement over `libstdc++.so.6 not found blah`). But breaking a library that statically links everything NVIDIA ever wrote precisely so that it will run anywhere because you have a canonical `CC` in your own `NIX_` environment variable prefix set and you just refuse to let grubby ubuntu software see it?

That's incompatible by design. // hypermodern // nixos has a principle that I realize isn't in the `README.md`: it's never incompatible by design for no upside.

Re: Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

#14

Post by yencabulator »

tadfisher wrote: post #8

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 esse…

Meanwhile, more and more software are turds that insist on overwriting their own config files :-(

Re: Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

#16

Post by alurm »

thayne wrote: post #15

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).

Yes, but you can generate JSON with other tools easily. home.md describes how you can do it with Nix, but just as easily you can use Cue or something else.

Edit: mentioned this in the README explicitly. Thanks!

Re: Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

#18

Post by bapak »

I guess this could be a cross-platform format but you could also just store it as a sequence of commands

    echo "Hello, world!" > file
    mkdir -p dir/subdir
    echo -n "Content.\n" > dir/subfile
    ln -s "target path" link
    printf '#!/bin/sh\necho Howdy!' > script
    chmod +x script
Would be the same as what's in the readme:

    {
    "file": "Hello, world!",
    "dir": {
        "subfile": "Content.\n",
        "subdir": {}
    },
    "symlink": ["link", "target path"],
    "script": ["script", "#!/bin/sh\necho Howdy!"]
    }

Re: Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

#19

Post by setheron »

tadfisher wrote: post #8

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 esse…

I agree and worry about that idea https://fzakaria.com/2025/07/07/home-manager-is-a-false-enli...

Re: Json2dir: a JSON-to-directory converter, a fast alternative to home-manager

#20

Post by jauntywundrkind »

alurm wrote: post #6
porridgeraisin wrote: post #4

Earlier quoted context omitted.

> file system to hold data 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…

Yeah, in general (a bit of a tangent), ideas from Plan 9 are really powerful. For example, the Acme text editor exposes it's API as a file system (it's represented via Unix sockets in plan9port, but FUSE is available as well there). It's easy to write scripts to manipulate the editor, and quite fun.

I 100% have been inspired plan9, not actually a tangent at all!

I never spent much time in Acme. I did use wmii as a daily driver window manager for a number of years, which was also 9p based! I wasn't great at scripting it, and the docs have always been basically non-existent for it's 9p interfaces... but I did poke around and look at things, which was super easy to do because it was just a filesystem! I did find this short example of some wmii examples, inside a Chicken Scheme 9p write-up, which is lovely to see online: https://wiki.call-cc.org/eggref/5/9p#utility-procedures

It's a fine distinction, but I do like json2dir and my own work a bit more than 9p because with apps that expose 9p, if the app goes away, so does the filesystem! 9p is an interface to talk to some process state. But if you just keep state on the regular filesystem, it will stick around & persist beyond the life of the process. The downside is your app needs to watch for that state changing, needs to be able to reconcile changes as they happen. On the upside though, now you can use a lot of great filesystem utilities: for example btrfs or zfs snapshots or incremental-backups are going to work as usual!

Being able to easily script your world is-I think- a missing key to unlocking personal computing. Different technologies discussed, but another serendipitous thread on personal computing from today: https://news.ycombinator.com/item?id=44837783

Post reply on HN