261: profilesTest/mkHosts: include host's configuration r=blaggacao a=Pacman99
Now that profiles test is done dynamically - first available host - we likely need to include the host configuration itself. I have profiles that depend on the domain being set, which how I ran into this, and I think other problems might occur if we don't include the full host in the profiles test.
targeting core, since its a small bug fix and was planned to make into a release.
Co-authored-by: Pacman99 <pachum99@gmail.com>
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.
