Giters

NixOS / nix

Nix, the purely functional package manager

Home Page:https://nixos.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Build capability interface

roberth opened this issue · comments

commented

Is your feature request related to a problem? Please describe.

Scheduling a derivation involves a comparison between a derivation's scheduling attributes (such as system and requiredFeatures), and the related properties of a "builder" (such as system, extra-platforms, supportedFeatures, mandatoryFeatures).

In #9899 I have done some exploratory coding to work out these concepts a little better.

Problems:

  • "builder" is overloaded. It occurs in the derivation builder attribute, as well as "remote builder", which have very different meanings, yet interact too closely.
  • the remote builder configuration is denormalized, which users don't expect, resulting in inaccurate remote builder configs
    • specifically, remote builders and build capabilities are in a one to many relationship
    • by denormalizing the config (repeating the remote builder connection part), connection reuse becomes less efficient
  • we don't have a good interface to stub out builds in unit tests
    • this leads to more configuration than desired (#10562)
    • unit test performance is slightly worse, for having to perform an actual build (an easily bearable cost, considering our current over-reliance on functional tests)
  • we don't have an interface to separate the store component from the builder component, whether that's an internal or IPC interface
    • local and remote builds feel like chaotic reimplementations of each other because we lack the clarity of such an interface
    • nix-daemon has to manage builds instead of just a store and a build capability trust relation

Describe the solution you'd like

  1. Define unambiguous terminology
    • I've renamed "builder" to "build capability" but maybe someone has a better term?
    • We should probably further distinguish between "build capability" and the concrete service or implementation that fulfills that capability, because these are again in a many to many relation.
  2. Define interface in C++.
  3. Define an IPC interface between nix-daemon and build process or build daemon (or whatever we want to call it).

Describe alternatives you've considered

Additional context

Efforts/ideas to add more "systems" which may or may not be the native system.

Priorities

Add 👍 to issues you find important.

commented

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-04-22-nix-team-meeting-minutes-140/44016/1