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.
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>
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.
Subflakes should provide their wares as outputs, so wire up the pkgs
flake to reflect that.
Due to the unstable nature of flakes, updating the root flake doesn't
currently update the subflake lock file. Therefore, add additional
logic to flk update script in order to do this behind the scenes.
Nix is now pulled in from the "nix" registry flake in order for users
to take advantage of improvements to the UI since its last update in
nixpkgs.
* Resolves#118
* Leverage flakes to manage package sources & hashes
* Update documentation with an example.
* Add `mkVersion` function to autogenerate a version string.
* Add srcs package via overlay containing all sources defined in
_pkgs/flake.nix_
* Extend `flk update` with the ability to only update the given input
Managing servers remotely is a big usecase, and deploy-rs is a flake
first deployment tool. By default, all nixosConfigurations are also
setup as deploy-rs nodes.
You'll still need to do some manual ssh setup, but other than that, the
system is ready to deploy.
- add nixos-hardware flake.
- configuration in hosts/default.nix to be able to include hardware
specifics per host.
- add corresponding documentation in readme
Now you can add packages to the list in pkgs/override.nix and they will
be pulled in from nixpkgs master instead of the default NixOS flake
when installed.
