225: lib: only readDir if path exists with safeReadDir r=nrdxp a=Pacman99
After doing this for the second time, I realized it might be good to make a lib function for it and do it across lib.
Create a function called `safeReadDir` that only uses `builtins.readDir` if the path exists. With `optionalAttrs` any function that relies on the output won't fail since they still get an empty attrset.
Then replace all uses of `readDir` with the safe version.
Co-authored-by: Pacman99 <pachum99@gmail.com>
224: Allow for directories in module-list r=nrdxp a=Pacman99
fixes#221
building on #222 this PR improves the lib functions pathsToImportedAttrs and pathsIn. First to add support for directories. This does not support actually passing a file in a directory, so `./matrix/default.nix` won't work but `./matrix` will - I should probably document this somewhere.
Also I moved the filtering for nix files to `pathsIn`, since its only necessary for auto-import. We can assume that users would pass proper files in `module-list.nix`.
Co-authored-by: Pacman99 <pachum99@gmail.com>
216: Move host and suite implementation logic to lib r=nrdxp a=Pacman99
This is just the `mkSuites` and `mkHosts` part of the `mkDevos` PR. I would like to avoid changing mkSuites and mkHosts api, to make it easier to rebase changes into the mkDevos branch. But if necessary we can change them. And to that end, there is some more logic added to the flake.nix now which would ideally not be there if devos was meant to be a template. But since the goal is to move towards a lib function with template, this is just a step in that direction.
Co-authored-by: Pacman99 <pachum99@gmail.com>
217: lib/mkPkgs: don't import external files and get inputs as argument r=nrdxp a=Pacman99
Changes mkPkgs to take extern, overrides, and pkgs as an argument. This improves their ability to be used as lib functions.
Co-authored-by: Pacman99 <pachum99@gmail.com>
`legacyPackages` are not filtered by system and so will contain invalid
derivations. If something in legacyPackages should be explicitly built
add it to the `checks` output.
220: Drop flattenTreeSystem and use custom function for filtering packages r=nrdxp a=Pacman99
I don't think we should flatten the system because if a user doesn't make a package a derivation in pkgs/default.nix we should trust that there is a reason for doing so. So instead this drops the flattenTreeSystem reference(and switches to flake-utils master branch) and replaces its usage with a custom function `filterPackages`. This function filter all packages that match three conditions;
- is a derivation
- not broken
- system is supported
In that order as to not cause errors when trying to reference non-derivation meta attributes.
And then also just dump *all* packages into legacy packages, so everything else is still accessible. I was considering removing the packages that are already in the packages output in legacyPackages, but I don't think its necessary since nix looks to the packages output first.
Co-authored-by: Pacman99 <pachum99@gmail.com>
215: lib/pathsToImportedAttrs: discard string context in the names to prevent flake check error r=nrdxp a=Pacman99
So I learned about this myself while working on it. Nix has a thing called string context, where strings refer to various store paths that they used to contain. This is normally a good thing to guarantee purity, but flake outputs cannot contain store paths. So when `pathsToImportedAttrs` is passed a list of store paths, and is then used for a flake output, we get a very confusing error that the string refers to a store path - even though it doesn't look like it does!
I think its good to review this as a separate Pr, since it requires calling an unsafe nix builtin.
Co-authored-by: Pacman99 <pachum99@gmail.com>
211: home-manager fixes r=nrdxp a=nrdxp
- [x] integrate nix-community/home-manager#1880 (to avoid duplicate commits, we'll wait a bit to see if this gets merged)
- [x] don't use all of `systemPackages` for `flk home`
- [x] test home-manager `activationPackage` and `flk home` as part of CI
Co-authored-by: Timothy DeHerrera <tim.deh@pm.me>
219: lib/mkPkgs: reorder overlays to get access to devos lib(dev) r=nrdxp a=Pacman99
nixpkgs applies overlays in the order given. This PR moves the lib extension overlay to be first so all subsequent overlays can access `dev` which is the devos lib.
Co-authored-by: Pacman99 <pachum99@gmail.com>
213: readme typo r=Pacman99 a=jackmac92
hopefully I can make a more meaningful contribution in the future, but this is all I got for now
Co-authored-by: Jack McCown <jackmac79@gmail.com>
212: lib/pathsIn: don't error if path doesn't exist r=Pacman99 a=Pacman99
Really simple, just don't error if path passed to pathsIn doesn't exist. This doesn't affect much, since the majority of folders in devos end up getting referenced in some way or another outside of a pathsIn call. But it will help for users of mkDevos, so they can safely delete folders they don't want to use.
Can test with current overlays folder in deovs, that only gets imported through a pathsIn call.
Co-authored-by: Pacman99 <pachum99@gmail.com>
To remove the opportunity for junk to enter into the changelog, and to
reduce the commit history, the changlog generation will only happen
on release, and only based on merged PRs.
Fixes#205
210: hosts: add cachix r=nrdxp a=Pacman99
fixes#208
I think it was dropped during #157. It used to be added to nixosModules, but I think its better added to hosts, I don't see a reason to export the cachix module as an output.
Co-authored-by: Pacman99 <pachum99@gmail.com>
156: Improve Home Manager support: profiles/suites, modules, extern, flake outputs r=Pacman99 a=Pacman99
A really simple method of implementing #119.
This relies on a feature that I added in home-manager master for module options of extraSpecialArgs and sharedModules, nix-community/home-manager#1793. I could try and get that backported to 20.09. But I thought I'd get some feedback on these changes first.
Co-authored-by: Pacman99 <pachum99@gmail.com>
192: flake: nixos -> nixos-unstable r=nrdxp a=nrdxp
20.09 is getting stale as we move toward a new release so track unstable for now.
Co-authored-by: Timothy DeHerrera <tim.deh@pm.me>
I originally wanted to use the nix flake to allow users to take
advantage of the latest changes. Just so happened that nixpkgs was
recently updated with a new version around the same time, and this
just adds complexity for no real gain.
