Tracking Issue: A Usable First Iteration of the `eka` CLI

[nrdxp]

Summary

This issue tracks the work required to implement a usable first iteration of the eka command-line interface. The goal is to create a user-friendly CLI that leverages the snix ecosystem for a more robust and decoupled store management, sandboxed execution, and a simple configuration interface. This work builds upon the proof-of-concept in the nixec crate and aligns with the "Evaluation & Execution" goals outlined in the project roadmap.

Core Architecture

The proposed architecture is as follows:

1. snix Content-Addressed Store (castore): We will use a snix castore as the fundamental Nix store for all eka operations. This provides superior caching and garbage collection properties compared to the legacy Nix store and includes a compatibility layer for legacy Nix calls.

2. Sandboxed Environment: All build and evaluation operations will occur within a sandbox. A snix blob-store will be mounted at /nix/store within this sandbox at runtime. We will use snix's nix-daemon to pass store paths to this mounted store. This approach has the significant benefit of not requiring users to have a system-wide, root-owned /nix/store, as the blob-store can reside in any user-writable location.

3. eka-run Shebang: For executing binaries that depend on /nix/store paths, we will introduce an eka-run shebang. Similar in spirit to nix-shell, this wrapper will first initialize the sandboxed store over the current working directory before executing the binary, ensuring its dependencies are available.

This architecture provides the isolation of flakes without the overhead, decouples eka from a system-wide Nix installation, and improves the overall usability and caching story.

MVP Scope

• Sandboxing & Execution:

  • Implement a sandbox that mounts a user-defined snix blob-store to /nix/store.
  • Integrate with snix's nix-daemon to manage store path resolutions.
  • Develop the eka-run shebang wrapper to execute binaries within the sandboxed context.

• User Entrypoint & atom-nix Integration:

  • Design and implement a basic user entrypoint for invoking atom evaluations.
  • Define a clear interface for passing configuration from eka into the atom-nix evaluation.

Future Work

• snix Store Integration:

  • Use a snix castore as the primary store for all eka operations.
  • Leverage the snix compatibility layer to ensure legacy nix calls function correctly.

• User Entrypoint & atom-nix Integration:

  • Ensure the interface is generic enough to support alternative Nix layouts in the future.
  • Normalize (e.g., to canonical JSON) and hash the passed configuration to tie the final artifact's integrity cryptographically to the atom's ID, version, and configuration.

• Generic Evaluator & Builder Interface:

  • Design a trait-based interface for the evaluator and builder.
  • Implement the initial version using legacy nix as the backend.
  • Ensure the interface is flexible enough to support future backends like snix with minimal effort.

• Configuration API:

  • Implement a configuration API to parse atom.toml.
  • Allow passing in system variables for features like cross-compilation.
  • Allow users to specify configurable variations that can be invoked at the CLI boundary.

• Core Commands:

  • Implement the eka resolve command to synchronize the lock file with the manifest. (largely done by the work for eka add)
  • Scaffold other necessary commands to invoke this runtime.