| 10 Apr 2026 |
 jaen | * | 12:38:33 |
 neobrain | nice, congrats! | 13:13:04 |
 magic_rb | Lol, you found out you got the grant cause you got pinged here? | 13:21:22 |
| magic_rb | Peak | 13:21:23 |
| jaen | It would be funny if I did, but no - I actually do read e-mails from time to time xD | 15:23:40 |
| jaen | I guess now I have to actually go and build this thing for real. | 15:26:18 |
| jaen | Gotta hold Ericson by his "we're making dyndrvs generally usable this year" because when I transitioned my PoCs from parsing at scale to building at scale it turns there sure is a bit of overhead to solve xD | 15:26:28 |
| neobrain | To me as a layperson the project sounds like it's solving a similar problem space as soongnix did.
Are they related at all or am I thinking in the wrong direction? | 19:50:21 |
 atemu12 | Depends on which way you build it. If you take the simple approach of basically doing nix-ninja, you don't interact with soong at all but that's unlikely to work in practice because drvs don't scale into the 100000s. | 23:05:53 |
| atemu12 | The hard way would be to build soongnix and run it inside a drv to get per-project drvs (100s) | 23:06:51 |
| 11 Apr 2026 |
| jaen | Yeah, It Depends™ | 01:48:50 |
| jaen | The MVP is writing a ninja parser that doesn't choke on how big AOSP is (that I have mostly mapped out), welding it onto nix-ninja (with a few CLI oddities Soong insists on) and seeing what falls out. Which will probably be "congrats, you now have loads of dyndrv profiling to do" and it is a bit of an open question how far you can go with optimisations. I don't think it's fundamentally impossible to get it to scale (bazel, for all of it being a giant PITA, somehow does it), but may end up not being practical. | 01:49:42 |
| jaen | Which is where the second part of it comes in - I'm trying to write it in a modular enough way, so you could decide to take out the ninja chunks, write some Soong piece and keep the rest of niceties for free. Or Grade, or Cmake, or Kbuild or whatever. I just picked AOSP as the first target because I was annoyed at how painful robotnix was to iterate on (until CyclicPentane came along and showed me I just sucked xD), but the idea is to provide something all whatever2nix tools could use. | 01:52:30 |
| jaen | And if it turns out that there's a hard ceiling to dyndrvs that makes the simple & dumb approach not work, then I guess I can always pivot to Sonngnix 2: Electric Bogaloo. | 01:54:43 |
| jaen | * | 01:55:04 |
| jaen | As far as I understand it, the biggest difference between the two is Soong(nix) being applicative (as far as I can tell) and dyndrvs (and thus shinobi) being monadic. It doesn't change much for AOSP build since applicative is strictly less powerful (you have to know the build graph ahead of time), but is in general more powerful (because you can modify the build graph during the build, when you discover new dependencies), so it doesn't hurt to try and leverage that, if practicable. | 02:02:24 |
| jaen | But I guess that's enough of off-topic for now | 02:02:43 |
 pentane | fwiw i think it's perfectly on-topic, and I'm also interested in this | 06:45:11 |
| magic_rb | Not yet enough offtopic. I never thought of dyndrv as being monadic while normally were in applicative land, but damn youre right | 06:55:49 |
| magic_rb | Does bazel do sandbox setup? Cause assuming you dont use stdenv for your dyndrvs, then the only real thing nix does except for a fork exec is the sandbox setup | 07:37:36 |
| magic_rb | Maybe if we could reuse the sandbox for a group of dyndrvs? | 07:37:50 |
| jaen | It does have sandboxing, but it is less strict about it than Nix. With Nix you have to really try to make something non-reproducible, while with Bazel it's the other way around - it's not too hard to end up with "FFS why it does break with remote execution". | 07:40:51 |
| jaen | I guess it's historically because for Nix hermeticity was the point, while for Bazel it was just means for an end (hard to do webscale builds if you can't reliably cache) | 07:42:10 |
| jaen | Possibly? But then the trade-off becomes, I think, cache granularity. | 07:47:06 |
| jaen | One of the few downsides of Nix as opposed to Bazel is the default build granularity - for Bazel you are encouraged to go as granular as a single file, for Nix is more natural to go at a package granularity. And depending on how you chunk you, end up with different incrementality and early cut-off trade-offs, I think. But "Builds Systems a la Carte" is probably going to explain this better than me. | 07:49:30 |
| jaen | I haven't tested this specifically for building things together, but at least for planning (that is, creating dyndrvs as you go) the exact trade-off is you either rebuild more or you eat more of the overhead. | 07:51:01 |
| jaen | My hope is that there was something obvious missed in the PoC and now that I'll get paid to write it myself, there will be some easy fix lurking. Or if it not, I'll just keep pestering Ericson for fixes/guidance xD | 08:01:34 |
| neobrain | Thanks for the explanation, that's super interesting. I didn't even know about nix-ninja, sounds like plenty exciting stuff is happening in this space :) | 08:25:17 |
| atemu12 | @jaen:matrix.org I'd highly recommend you try to dyndrv a bunch of stubs to test scaling before you try to make it work with a real build system | 10:09:35 |
| atemu12 | IIRC I did something similar once and discovered sandbox creation overhead to be so massive that this granularity is simply infeasible | 10:10:45 |
