This helps to split up the code in mkHosts and creates a place where we
can store modules relevent to devos. It will also be easier to remove
unecessary parts of each module in the future when they are all
compartmentalized.
With mkFlakeDoc in packages there is no need for jobs. And I think
anything that could go in jobs really should go in checks or packages.
If something needs to be tested - checks, if something needs to be built
- packages. jobs is not multi-arch and is redundant to build/test
things with when official flake outputs exist
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.
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.
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.
231: Move flake implementation logic to lib r=nrdxp a=Pacman99
This is a simpler version of #218 that moves flake logic to lib and adds a module to evaluate devos. This DOES NOT support out of tree usage, so if you were following any of the previous PR's, the doc sections/examples to use devos as a library will not work. There is work to make a cleaner api and only then will out of tree support work. Until then, this is still useful to simplify devos and clean up a lot of the implementation logic.
Co-authored-by: Pacman99 <pachum99@gmail.com>
