Hey folks, I’ve been prototyping a Lua-based interpreter that generates .drv files like the main Nix interpreter does. I wanted to see if something like this would be possible, since I’ve observed one of the friction points in onboarding folks onto Nix in an enterprise setting is concern about learning a new programming language.
I’m just one person, so I’m not planning on developing it to a full production-ready program. I wanted to share it in case the idea or implementation is interesting to anyone else, and figured folks here might have thoughts. 
Blog post summarizing the project: Zombie Zen - zb: A Build System Prototype
GitHub repository: GitHub - zombiezen/zb: zombiezen build tool
Happy to field discussion here, on the repository, or privately. Cheers!
10 Likes
That project seems very interesting! I genuinely believe that nix the language is a huge gatekeeper.
And I’d love to see you keep working on it.
But IMO any nix-like tool without something similar to the nixpkgs stdenv & lib isn’t even comparable. Nixpkgs should be the target. nix is “just” the way we got to it.
I have (sadly?) strong believes that you’ll run into various hard-to-solve issues if you try to go a step further and build a nixpkgs-like project ontop of this (e.g. stuff like lazy evaluation), but I would love to be proven wrong!
Definitively going to read some of your blog posts
3 Likes
Absolutely agreed that the package set is a vital part of the user experience. IMO the prototype shows that this is possible by either leveraging nixpkgs itself through interoperability, or by bootstrapping, which is feasible, but requires ongoing maintenance by many people to get right.
I’ve built enough out that I’ve convinced myself that zb is already a reasonable base: Lua supports laziness through meta-tables, I just haven’t gotten around to sketching that out. I’m of the opinion that as long as a language supports the string-with-dependency-information trick that Nix acquired, the rest of the functional programming language parts aren’t as necessary and can be done with library support. In fact, I rather appreciated that in my prototyping that Lua would raise errors that I introduced about packages that I hadn’t built yet, and with easy stack traces to follow.
2 Likes
This post actually inspired me to write a simple lexer/builder for nix derivations! Its still super duper early cuz I literally just started working on this today at 3AM, but maybe this will be kinda cool, right? tulilirockz/Nanev: Experimental Nix derivation parser and builder aiming to be a replacement to nix-store --realise, --eval, and others - Codeberg.org
2 Likes