Introduction
Nix is renowned for its ability to manage dependencies in an isolated and reproducible manner. However, one challenge remains: the need for relocatable binaries. Currently, the store prefix is embedded in every derivation, complicating integrations with tools like Bazel or Buck2.
The Problem with Fixed Prefixes
Store-based systems like Nix and Guix use a well-defined prefix to store all packages. This simplifies rewriting paths to binaries or libraries. For instance, a bash binary becomes /nix/store/gik3rh1vz2jlgnifb9dh6vc6sxwwz9jj-bash-5.3p9/bin/bash. But what if you want to use a different path, not prefixed at the root?
Integration Challenges
Imagine you want to integrate Nix into an ecosystem that already uses its own sandboxing through namespacing, like Bazel. Integration becomes impractical due to nested user namespace and mount restrictions. Currently, changing the store prefix invalidates the entire dependency graph, potentially leading to hours of compilation.
A Potential Solution: Relocatable Binaries
To address this problem, Nix needs relocatable binaries. This means being able to install Nix binaries anywhere without using namespacing or chroot. One approach could be using relative paths instead of full prefixes. This would maintain the same hash and leverage existing public binary caches, avoiding lengthy compilations.
The Impact of Relocatable Binaries
Adopting relocatable binaries could dramatically improve Nix's integration into various development environments. This would make the tool more flexible and accessible, especially for open source projects and environments with limited privileges.
Conclusion
Making Nix a system with relocatable binaries is not just about convenience but a necessity for its broader adoption in modern development environments. By solving this issue, Nix could become an indispensable tool for developers looking to optimize their workflows.
Let's discuss your project in 15 minutes.