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
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.
Define interface in C++.
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.
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
andrequiredFeatures
), and the related properties of a "builder" (such assystem
,extra-platforms
,supportedFeatures
,mandatoryFeatures
).In #9899 I have done some exploratory coding to work out these concepts a little better.
Problems:
builder
attribute, as well as "remote builder", which have very different meanings, yet interact too closely.Describe the solution you'd like
Describe alternatives you've considered
Additional context
Efforts/ideas to add more "systems" which may or may not be the native system.
2759
Priorities
Add :+1: to issues you find important.