|
| 1 | +# For the derivation builder insider to communicate with Nix |
| 2 | +interface org.nix.derivation-builder |
| 3 | + |
| 4 | +type DerivationOutput ( |
| 5 | + # Note, not needed for floating content-addressing derivations. |
| 6 | + path: ?string, |
| 7 | + method: ?string, |
| 8 | + hashAlgo: ?string, |
| 9 | + hash: ?string |
| 10 | +) |
| 11 | + |
| 12 | +type Derivation ( |
| 13 | + name: string, |
| 14 | + outputs: [string]DerivationOutput, |
| 15 | + # TODO, combine both types in to just "sources" |
| 16 | + inputSrcs: []string, |
| 17 | + # Approximate typing |
| 18 | + inputDrvs: [string]object, |
| 19 | + system: string, |
| 20 | + builder: string, |
| 21 | + args: []string, |
| 22 | + env: [string]string, |
| 23 | + # Intentionally freeform, as the point of this is being extensible. |
| 24 | + # Implementations should reject what they don't understand. |
| 25 | + options: ?[string]object |
| 26 | +) |
| 27 | + |
| 28 | +# Add a file to the store. |
| 29 | +# |
| 30 | +# Parameters: |
| 31 | +# - name: file name |
| 32 | +# - method: content addressing method ("sha256", etc.) |
| 33 | +# - fd: file descriptor number to read from |
| 34 | +# |
| 35 | +# Returns: |
| 36 | +# - path: resulting store path |
| 37 | +# |
| 38 | +# The references should be scanned based on the starting possible |
| 39 | +# reference set of all derivation inputs, and all previously-added store |
| 40 | +# objects. (Ever sucessfull add, this possible reference set grows one |
| 41 | +# bigger.) |
| 42 | +method AddToStore( |
| 43 | + name: string, |
| 44 | + method: string, |
| 45 | + fd: int |
| 46 | +) -> (path: string) |
| 47 | + |
| 48 | +# Add a derivation to the store. |
| 49 | +# Parameters: |
| 50 | +# - derivation: derivation in JSON format |
| 51 | +# Returns: |
| 52 | +# - path: store path of the derivation (in format) |
| 53 | +method AddDerivation(derivation: Derivation) -> (path: string) |
| 54 | + |
| 55 | +# Submit an output, associating an output with a store object. |
| 56 | +# |
| 57 | +# Parameters: |
| 58 | +# - name: name of the output |
| 59 | +# - path: path of the store object (must already exist in store) |
| 60 | +# |
| 61 | +# The idea is derivations should add and submit their outputs one at a |
| 62 | +# time. This allows a few things: |
| 63 | +# |
| 64 | +# 1. Interesting pipeling. If something downstream just needs e.g. a |
| 65 | +# "dev" or "headers" output, it need not block on waiting for the other |
| 66 | +# outputs of the upstream derivation. |
| 67 | +# |
| 68 | +# 2. Content addressing doesn't require Nix-side rewriting. Instead, it |
| 69 | +# is the responsibilty of the builder to add outputs in reference order, |
| 70 | +# and arrange for the store paths that resulted from earlier adds being |
| 71 | +# used in later adds. This takes would be a very hard problem to solver |
| 72 | +# in "build system space", and punts it back to userspace, where |
| 73 | +# arbitrary strategies can be employed. |
| 74 | +method SubmitOutput(name: string, path: string) -> () |
0 commit comments