@vivekanandanks I'm using snix-nar-bridge from the snix project (https://snix.dev/) (a fork/rename of tvix) as a binary cache.

I have no experience using the project for anything else. Take a look at https://snix.dev/contact/.

#snix

@guix @civodul

It's indeed a really nice presentation!

Unfortunately the common roots with #nix and the shared daemon code are more or less forgotten now and suppressed by an all-dominating "scheme and nothing else" ideology. This makes the project utterly blind for any interesting development and improvement attempts going on in the nix sphere -- e.g. the #snix efforts.

@michaelcoyote NixOS is decades old.

share the issue you’re having.

I feel that NixOS is unparalleled but it takes dedication.
Once something works, it just works; delivers what Docker pretends to.

For me, flakes allow me to lock in my dev env & builds.

That said, I can’t help but think that #Nix is the precursor to something ideal.
The only thing standing in Nix’s way is the stack they chose long ago.
IMO, Nix being untyped was a mistake.

#GUIX #Sixos #nickel #tvix #aux #lix #snix

@katzenmann @nixos_org One of the hurdles is stabilizing an underlying feature like fetchTree. @domenkozar is doing some great work on that with an alternate implementation of it in #SNix, exposing some of the unfortunate choices that all #Nix implementations should backtrack on.

This may lead to a small change in behavior in Flakes that would not be considered acceptable normally for non-experimental parts of Nix, but will be necessary in order to fix various problems that exist within Flakes.

For a user of Flakes, this means that you may have to put up with a binary cache miss, or synchronizing your Nix update with your team, but you shouldn't have to overhaul your code or anything.