The Guix-Nix Symbiosis: When Rival Ecosystems Share the Same DNA
#DevOps

The Guix-Nix Symbiosis: When Rival Ecosystems Share the Same DNA

Tech Essays Reporter
4 min read

Despite appearing as separate ecosystems, Nix and Guix share a fundamental common architecture that enables surprising interoperability, allowing derivations from one system to be built by the other.

The relationship between Nix and Guix has long been characterized as a rivalry between two distinct package management ecosystems. Yet, as Farid Zakaria demonstrates in his recent exploration, these systems are more akin to different dialects of the same language than truly separate entities. The article reveals a profound truth: beneath their surface differences, Nix and Guix operate on the same fundamental principles, sharing what Zakaria aptly calls the "Input Output Machine".

At the core of both systems lies the concept of derivations—hermetic build recipes that declare all dependencies needed to produce an output. This shared foundation becomes evident when we examine how a Guix derivation can be built using Nix, as demonstrated in the article's initial proof of concept. By creating a simple "Hello World" derivation in Guix and then instructing Nix to build it—after some clever configuration to avoid store collisions—the author successfully bridges what appears to be a fundamental divide.

The technical execution of this feat reveals the remarkable similarity between the systems. Both take a language frontend—Nix or Guile (Scheme) in Guix's case—that compiles to a derivation format, then pass this to a builder daemon that executes it. The hermetic nature of these builds is what makes both systems special: everything needed to build the output is explicitly declared in the recipe, ensuring reproducibility and eliminating environmental dependencies.

This shared architecture becomes even more apparent with the introduction of the guix-transfer tool, a CLI utility that performs bottom-up translation of GNU Guix derivations into Nix format. The tool demonstrates that Guix is not merely similar to Nix but effectively a superset of it, capable of being translated with remarkable fidelity. The translation process involves several key steps:

  1. Replacing Guix's builtin:download with Nix's builtin:fetchurl
  2. Adding source files to the Nix store with embedded /gnu/store paths rewritten to /nix/store equivalents
  3. Rewriting all /gnu/store references—including input derivations, builder paths, arguments, and environment variables
  4. Blanketing output paths as Nix recomputes them via hashDerivationModulo
  5. Serializing the result as JSON and registering it with nix derivation add

What makes this translation possible is the fact that derivations themselves are system-agnostic recipes. They don't "know" whether they originated from Scheme or Nix. As the article explains, "By rewriting store paths and swapping builtins, the Nix daemon can build Guix derivations." The bootstrap seeds—those fundamental packages like gcc, awk, bash, and tar that form the leaves of any non-trivial derivation graph—don't depend on /gnu/store being the prefix, allowing the translated chain to build identically under Nix.

The implications of this interoperability extend far beyond a technical curiosity. In practical terms, it effectively expands the available packages in both ecosystems. Nixpkgs, already described as "the world's largest package repository," can suddenly incorporate any derivation from Guix, dramatically increasing its scope. This could lead to greater collaboration and cross-pollination between the communities, potentially accelerating innovation in both ecosystems.

The article demonstrates several practical applications of this interoperability. Translated Guix packages can be used in native Nix expressions, either by directly referencing the store paths or by generating Nix expressions from Guix derivations using guix-transfer's --emit-nix mode. This flexibility opens the door to creating flakes that make all Guix packages available for use in Nix, effectively merging the package repositories of both systems.

However, this interoperability is not without its challenges. The article notes several technical hurdles, such as differences in bootstrap processes—like the seccomp filter issue where Nix's sandbox blocks chmod calls that set setuid/setgid bits, while Guix's Scheme-based tar treats this error as fatal. These subtle differences highlight that while the systems are similar, they're not identical, requiring careful handling during translation.

The philosophical implications of this work are equally significant. By demonstrating that derivations from one system can be faithfully executed by the other, the article underscores that the core innovation of these systems—their hermetic, reproducible build approach—is more important than the specific implementation details. This suggests that the derivation-based model represents a fundamental advancement in package management that transcends any particular implementation.

As we consider the future of these systems, this work opens intriguing possibilities. We might envision a future where the communities collaborate more closely, leveraging each other's strengths while maintaining their distinct identities. The ability to translate between derivations could facilitate migration between systems, enable hybrid approaches, and foster greater experimentation with build technologies.

In the end, what began as an exploration of "abomination" has revealed something more profound: the deep architectural kinship between what appeared to be rival systems. This realization not only bridges a technical divide but also offers a glimpse into the future of package management—one where the boundaries between ecosystems blur, and the shared principles of reproducibility and hermeticity unite what were once considered separate worlds.

For those interested in exploring this interoperability firsthand, the guix-transfer tool represents a significant step forward. As the article demonstrates, it's now possible to take a Guix derivation, translate it to Nix, and build it using Nix's tools—all while preserving the hermetic, reproducible nature that makes both systems valuable. This capability doesn't just merge package repositories; it merges the very essence of what makes these systems powerful.

The full technical details and examples from Farid Zakaria's blog can be found at The Guix Nix Abomination: Leveraging Guix derivations in Nix, where the author provides comprehensive code examples and step-by-step instructions for building and using the guix-transfer tool.

Comments

Loading comments...