Conversation
Update evalArgs to match the new planned API
for clarity's sake, expose which function uses final and prev, so that
people can have a clearer understanding how they relate to each other
in terms of dependencies.
also a simple `{ lib = final; }` probably does not warrant a complete
callLibs obscurization.
if functions where contructors
Intermediate version of api-next
allow lists, nested lists, and non-lists for list like options drop config.<name>.externalModules
used coercedTo for typing and improve options
in devos, we differentiate clearly between home and os configuration, reason for which we are more precise by not naming after the (more generic) fup API.
ref: config -> hosts | nixos -> os
fix pathTo and coercedList types add modulesModule to also include modules option under home
Also format all files and add a flake.lock for lib for a folder thats meant to work on other flakes theres never a reason it should need to refer to itself, only other flakes. So "self" and "inputs" are better namings for these variables. The userFlake* is redundant and confusing, when trying to call the functions its hard to figure out how to use them when there are now two lines of arguments to figure out.
I think auto-importing should be done in I like this method, since its clear where auto-importing is happening and anyone that isn't a fan can just remove those lines. and use The only exception to me is |
drop ca experimental features and filterPackages improvements
includes ability to customize shell from template
Co-authored-by: David Arnold <dar@xoe.solutions>
its already imported in the core profile
includes nixos option improvements and importHosts change
This makes the auto-importing of hosts obvious and explicitly indicates how the options would end up getting merged.
tree: rename devlib -> digga
allows overlays to also be used with `imports` and renames importHosts
|
bors try |
tryBuild succeeded: |
|
bors r+ |
|
Build succeeded: |
3 participants
Core is starting to get pretty stale. All the changes in
developare pretty stable and I think we should encourage updating to them. As most future updates can be done through devlib, so once you switch to this version of the template. Updating to new changes will be much simpler (ie #91).