You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current API involves inputsExtender and exporter objects.
inputsExtender objects can use self.initInputs to set an inputs attribute. All the inputs attributes will be merged to create the final inputs set passed to exports. Inputs passed to inputsExtender will be de-systemized.
Exporter objects can use self.inputs and self.system to set an exports attribute. If an exporter doesn't want its exports to be system-spaced then system can be set to whatever system inputs should be passed for. For example a nixosConfigurations exporter could set the system to the one it will build configurations for.
The flake object extends both objects above and adds functionality to manage a list of inputsExtenders and exporters. A flake object is initialized for a specific system. It's inputs attr is the final inputs created by the inputsExtenders and it will be passed to all exporters. The exports attr merges all exporters together into exports meant to be system-spaced and general exports.
To finally build outputs for your flake with proper system-spacing, you can call the outputsForSystems method in the flake object - after you have added your inputsExtenders and exporters with the add* methods.
The goal is for this to be very minimal and generic so it can be built upon. I can imagine a host exporter that implements digga-like features. Or an exporter that loads in cells and blocktypes to build exports like std. Since exporters themselves are objects, they can have their own methods that users can call before adding it to their flake object.
I have an very simple example flake definition, that somewhat outlines how this all works,
Current API involves
inputsExtender
andexporter
objects.inputsExtender objects can use
self.initInputs
to set aninputs
attribute. All theinputs
attributes will be merged to create the final inputs set passed to exports. Inputs passed to inputsExtender will be de-systemized.Exporter objects can use
self.inputs
andself.system
to set anexports
attribute. If an exporter doesn't want its exports to be system-spaced thensystem
can be set to whatever system inputs should be passed for. For example anixosConfigurations
exporter could set the system to the one it will build configurations for.The flake object extends both objects above and adds functionality to manage a list of inputsExtenders and exporters. A flake object is initialized for a specific system. It's
inputs
attr is the final inputs created by the inputsExtenders and it will be passed to all exporters. Theexports
attr merges allexporters
together into exports meant to be system-spaced and general exports.To finally build outputs for your flake with proper system-spacing, you can call the
outputsForSystems
method in the flake object - after you have added your inputsExtenders and exporters with the add* methods.The goal is for this to be very minimal and generic so it can be built upon. I can imagine a host exporter that implements digga-like features. Or an exporter that loads in cells and blocktypes to build exports like std. Since exporters themselves are objects, they can have their own methods that users can call before adding it to their flake object.
I have an very simple example flake definition, that somewhat outlines how this all works,
flops/flake.nix
Line 212 in 4649807
The text was updated successfully, but these errors were encountered: