Hey, thanks for asking. I'll provide some context and say more about the project.
---
About the rewrites and why I posted now. So I wouldn't say that it's crystal clear to me what happened in other people's minds, but my read of the story is that I got a person I know riled up, and then they decided to express their frustration by like rewriting my project in Zig I guess? Either way, some other people I know saw this and jumped on the train and started rewriting the project in different programming languages. So it's kind of a joke. Most of the reimplementations are vibecoded I believe, yeah (mine isn't).
So yeah, I don't really have much to do with the reimplementations, nor did I make the "spec" mentioned elsewhere in this discussion. I'd say that the README of the project is the spec already. I did send a PR to one of the rewrites to link back to my project however.
So I thought I might as well post about my original project here now. I wanted to post about it for a while on here, but couldn't bring myself to write a proper blog post about it. So posting just the link to the repo is better than nothing I guess :)
---
About the project itself and how it came to be. The project and the idea of representing directory trees in JSON turned out to be quite general, but I personally had quite a specific issue which made me make it. I was using Nix on a shared computer with no root access via nixsa and it was working fine, but I couldn't install home-manager. But I wanted to manage my dotfiles and packages with Nix so I was looking for a solution. Generating JSON with Nix seemed simple enough to me so I made the project.
So yeah, it works as an alternative to home-manager (and GNU Stow and other similar stuff) to me. Concretely, nix profile and nix eval subcommands are used extensively.
It's a middle ground between the functional nature of Nix and imperative pragmatism to me. Files themselves are mutable, and therefore it's easy to make quick changes, but the source from which JSON is generated is stored in version control. There's a possibility of drift, but it hasn't been much of a problem for me in my experience. So it works as a nice compromise to me. Also, it's simple to understand compared to the fancy stuff which e.g. home-manager does I guess? I don't really understand how home-manager works. And my solution is fast enough and predictable to me. It also lets you abstract over configuration since the JSON can be generated from a normal programming language, so it makes more sense to me compared to using GNU Stow, which doesn't really support doing that.
I describe a simplified way to use it with Nix here.
My actual config is here.
---
By the way, I accidentally forgot to mark that I'm the author of the linked material, for which I apologize. Not sure how to properly report that, or whether I can fix this myself. So I would appreciate if someone could like fix this.
1 point
Mentions
Hey, thanks for asking. I'll provide some context and say more about the project. --- About the rewrites and why I posted now. So I wouldn't say that it's crystal clear to me what happened in other people's minds, but my read of the story is that I got a person I know riled up, and then they decided to express their frustration by like rewriting my project in Zig I guess? Either way, some other people I know saw this and jumped on the train and started rewriting the project in different programming languages. So it's kind of a joke. Most of the reimplementations are vibecoded I believe, yeah (mine isn't). So yeah, I don't really have much to do with the reimplementations, nor did I make the "spec" mentioned elsewhere in this discussion. I'd say that the README of the project is the spec already. I did send a PR to one of the rewrites to link back to my project however. So I thought I might as well post about my original project here now. I wanted to post about it for a while on here, but couldn't bring myself to write a proper blog post about it. So posting just the link to the repo is better than nothing I guess :) --- About the project itself and how it came to be. The project and the idea of representing directory trees in JSON turned out to be quite general, but I personally had quite a specific issue which made me make it. I was using Nix on a shared computer with no root access via nixsa and it was working fine, but I couldn't install home-manager. But I wanted to manage my dotfiles and packages with Nix so I was looking for a solution. Generating JSON with Nix seemed simple enough to me so I made the project. So yeah, it works as an alternative to home-manager (and GNU Stow and other similar stuff) to me. Concretely, nix profile and nix eval subcommands are used extensively. It's a middle ground between the functional nature of Nix and imperative pragmatism to me. Files themselves are mutable, and therefore it's easy to make quick changes, but the source from which JSON is generated is stored in version control. There's a possibility of drift, but it hasn't been much of a problem for me in my experience. So it works as a nice compromise to me. Also, it's simple to understand compared to the fancy stuff which e.g. home-manager does I guess? I don't really understand how home-manager works. And my solution is fast enough and predictable to me. It also lets you abstract over configuration since the JSON can be generated from a normal programming language, so it makes more sense to me compared to using GNU Stow, which doesn't really support doing that. I describe a simplified way to use it with Nix here. My actual config is here. --- By the way, I accidentally forgot to mark that I'm the author of the linked material, for which I apologize. Not sure how to properly report that, or whether I can fix this myself. So I would appreciate if someone could like fix this.