coffee-cup

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.

Author 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.

You are correct in that Nixpacks uses the languages own package manager instead of installing all dependencies with Nix using tools like node2nix, cargo2nix, or poetry2nix. This was a choice as the main problems Nixpacks aims to solve are with system dependencies and getting an environment where your app can install and build with as little configuration as possible. While continuing to use the same tooling that app authors are likely using locally (e.g. npm, pip, cargo). We have found that nixifying all possible deps often creates situations where the app author must know that Nix is being used under the hood and modify their app accordingly. Nothing against these tools, but using them didn't provide the experience we set out to have. If a user of Nixpacks wants to override the install command to `do_something && npm install`, they should be able to without worrying about how it affects the Nix store.

However, any Nix package can be installed, including from python-packages.nix, and we are planning on allowing more Nix config and customization in the future.