This is super exciting! Congrats on standing up all the infra to make this happen, and I look forward to working with y’all.
I’m glad to see the Lix infra code is sufficiently reusable as to provide a nice template for building out a project with similar needs, hope we can share effort on this stack because it’s quite nice! ^-^
For context: looking around, this is an identical software stack to lix with a bunch of lix-originated patches to forgejo applied. This is a very good thing, our patches are good, and we have worked out all the kinks; I expect snix to have a good contributor experience right out of the gate.
unserious comment: it could be more pink 
Cool! I wish you the best of luck with this endeavour.
Out of curiosity, since I can’t seem to derive this from the post; is this moving all development to the snix project, or will tvix and snix coexist and be developed in parallel to each other?
Thanks!
I decided to do (and move to) this new fork for the reasons described in the post, others might resonate and switch. Time will tell whether there’s gonna be two actively developed projects (like Nix/Lix, with some cross-pollination),or whether one branch is gonna stall, or things merge in the end.
Love these positive vibes 
Godspeed!
BTW Github mirror link gives 404 for me.
Awesome!
I have a few questions about contributing:
I noticed the Forgejo has both Gerrit and Forgejo Pull Requests enabled, are Forgejo Pull Requests intentionally enabled and supported? How does that integrate with code review?
Is there still a mailing list / place to send multi-commit patchsets other than Forgejo PRs?
I’ve spent last weekend familiarizing myself with the tvix codebase, tried getting the OCI builder to run, and then started looking into how to implement a macOS sandbox build backend, so I’m very excited to hear this news!
Hi there, the idea is to do a similar setup akin to Lix, that is: Forgejo PRs are disabled and you are recommended to send changes over the Gerrit instance.
If you find out you can actually send Forgejo PRs via the CLI or API, it’s a mistake on our end that will be fixed shortly.
Yeah, this was an oversight and has been fixed.
Originally I wasn’t extremely excited at hearing about another Nix-style fork, however after reading the blogpost I realize that it was a necessity given the issues present with having it as part of TVL. In that sense, I’m extremely excited to see progress and changes made as I was always extremely intrigued by Tvix when I first heard of it.
Out of curiosity, would you/your team be willing to eventually work together with Lix on propping one codebase? I know Lix was also exploring a Rust-written Nix, and I think it’d be awesome if that happened. My main intent behind asking is honestly just hoping that I see less fragmentation in the Nix ecosystem and more collaboration, especially since it seems Nix itself retains the COI issues as it has.
(What does COI mean here?)
Conflict of interest, presumably
What @phaer said is correct, conflict of interest. Mostly spurred by the recent events here: Determinate Nix 3.0 - Links - NixOS Discourse
Off topic, butdoes that mean Nix-based monorepo as managed by TVL is not best suited for developing projects with conflicting priorities?
If you had a do-over, what would you change?
Talking mostly for me, but I was a Tvix developer (now Snix) and I am a Lix developer. I am definitely interested into seeing how close pollination can happen but it will take some time for things to defragment themselves because the focus are different, the userbase are different.
I’m really excited to see Snix! I’d love to see an FAQ because I’m sure the same questions have been asked many times. For example, “when can we expect to see top level NixOS builds with Snix?” Is top of mind to me. I’d love to try my hand at creating a deployment service with embedded Snix, but I imagine Snix is not at top-level builds yet and more so at an individual package level. But maybe I’m wrong?