Why We're Moving on from Nix
blog.railway.com
Why We're Moving on from Nix
1–5 of 5 posts
Re: Why We're Moving on from Nix
#2[deleted]
Re: Why We're Moving on from Nix
#3Author here. We've been using our Nix based build tool for nearly 3 years (and 14M+ builds) and have came to the realization that the way we used Nix was problematic. So we've starting building a new non-Nix based tool that generates BuildKit LLB directly and allows us to store virtual lock files for user dependencies so that builds are more stable.
Re: Why We're Moving on from Nix
#4Author here. We've been using our Nix based build tool for nearly 3 years (and 14M+ builds) and have came to the realization that the way we used Nix was problematic. So we've starting building a new non-Nix based tool that generates BuildKit LLB directly and allows us to store virtual lock files for user dependencies so that builds are more stable.
Have you tried GNU Guix (the package manager, not the system) as a viable option to replace your Nix usage?
Re: Why We're Moving on from Nix
#5Author here. We've been using our Nix based build tool for nearly 3 years (and 14M+ builds) and have came to the realization that the way we used Nix was problematic. So we've starting building a new non-Nix based tool that generates BuildKit LLB directly and allows us to store virtual lock files for user dependencies so that builds are more stable.
Have you tried GNU Guix (the package manager, not the system) as a viable option to replace your Nix usage?
We have not, but I feel we would run into many of the some problems that we had with Nix around version management and interaction with the non-Nix world. Guix looks great if you go all in, but on Railway we don't want our users to have to understand the specifics of how the package manager works, and that becomes difficult with pure solutions like Nix and Guix. That said I'm not too familiar with Guix so could be incorrect on a few things.