57 lines
1.4 KiB
Markdown
57 lines
1.4 KiB
Markdown
|
|
# Lib Outputs
|
||
|
|
|
||
|
|
This note covers `42-lib-outputs/`, which exposes a `lib` attrset with pure data and helper functions that other outputs can reuse.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 1. Why `lib` Is Useful
|
||
|
|
|
||
|
|
Only some output names have special meaning to the `nix` CLI. A flake can still expose arbitrary attrs for consumers.
|
||
|
|
|
||
|
|
`lib` is a common convention for that. It is a good place for:
|
||
|
|
|
||
|
|
- pure helper functions,
|
||
|
|
- derived lookup tables, and
|
||
|
|
- reusable domain data.
|
||
|
|
|
||
|
|
This example keeps the `lib` attrset small so the distinction is clear: the flake exports logic, not just build targets.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 2. What the Example Exports
|
||
|
|
|
||
|
|
The `lib` output contains:
|
||
|
|
|
||
|
|
- `rolloutPlan`, a small list of pure data,
|
||
|
|
- `ownerByService`, derived from that list, and
|
||
|
|
- `renderStep` plus `renderPlan`, which turn the data into text.
|
||
|
|
|
||
|
|
The package output then prints `self.lib.renderPlan`, so the runnable artifact is built from the same exported helper values that outside consumers can evaluate.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 3. Why the Check Uses `self.lib`
|
||
|
|
|
||
|
|
The check reaches back through the public output path:
|
||
|
|
|
||
|
|
```nix
|
||
|
|
apiOwner = self.lib.ownerByService.api;
|
||
|
|
workerLine = self.lib.renderStep (builtins.elemAt self.lib.rolloutPlan 1);
|
||
|
|
```
|
||
|
|
|
||
|
|
That matters because it proves the helper data is not only local implementation detail in a `let` block. It is part of the flake interface.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 4. Commands to Try
|
||
|
|
|
||
|
|
```bash
|
||
|
|
cd 42-lib-outputs
|
||
|
|
|
||
|
|
nix flake show
|
||
|
|
nix eval .#lib.ownerByService.api --raw
|
||
|
|
nix build
|
||
|
|
./result/bin/show-lib-plan
|
||
|
|
nix flake check
|
||
|
|
```
|