Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to rework and simply some parts of
./modules
.Currently we use a DIY inhertitance scheme to pass options from the plan down to packages and then to components. This basically relies on manually chaining default values to use in
mkOption
. E.g.This is unnecessary as the module system is perfectly able to express default values and their override.
Also this cleans up a strange patterns of passing arguments to module-producing functions only for the returning module to add those arguments to
_module.args
. Why not adding those arguments to_module.args
directly?where
What this PR does is:
componentOptions
andpackageOptions
(minus what's already incomponentOptions) to separate option-defining modules
./component-options.nixand
package-options.nixkeeping the default value which would result from
def = {}`.componentOptions
(orpackageOptions
) was used to populateoptions
, I have instead imported./component-options.nix
(orpackage-options.nix
).There might be a better way to express it but this seems to work.
package.nix
and into a separate filecomponent.nix
/component-options.nix
andpackage-options.nix
which we can now see are always used toghether, so we might think of merging them intoshared-component-package-options.nix
.All these changes are intended to be semantic preseving and I don't to change any of the resulting derivations. Even the API should be exactly the same, a part from the exposure in
haskellLib.types
oflistOfFilteringNulls
,getDefaultOrNull
anduniqueStr
which where previously hidden inmodules/plan.nix
. These types can be hidden again if that's desiderable.I have verified nothing changes in the derivation of cardano-node as follows:
I am trying to extend the comparison to
hydraJobs.required
but I am running into some issues due to cardano-node flake's reliance onself.rev
. I will update.