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.
library functions now can access inputs (and their sources!)
directly, for example in order to copy their closure into
the iso registry so that evaluating the flake does not need
to fetch inputs again
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.
- [x] refactor lib into separate files, similar to NixOS/nixpkgs/lib.
- [x] refactor ci to automatically generate derivations from flake outputs
- [x] remove cluttered indirection statements throughout the codebase
- [x] refactor hosts to allow for upcoming integration tests
- [x] improve ambiguity in the existing docs
- [x] add [BORS](https://bors.tech) support
- [x] add initial integration test
- [x] write tests documentation
- [x] test lib
- [x] improve version string generation, and do so automatically for pkgs/flake.nix sources
Clean up the codebase as best we can in preparation for #152 and add tests. From now on, all PRs will be merged with BORS.
* 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.
* Move extern lists to their own folder
* Move unstable package and module imports to their own folder
* Create a genPkgs function to avoid using legacyPackages for the whole
package set
* Move hmActivationPackages to legacyPackages
* fix nixos-option
* use flake-compat for all backward compat concerns
* rebuild devshell after any nix file changes
* reexport system pkgs as legacyPackages
* provide lib flake output
* provide flake lib to nixos configs via `lib.flk`
* clean up flake.nix
- add nixos-hardware flake.
- configuration in hosts/default.nix to be able to include hardware
specifics per host.
- add corresponding documentation in readme
The baseline pkgs for own consumption is nixos, only pkgs/override.nix
provides a mechanism to "backport" packages from unstable.
Therefore, we should expose our packages to others in the same
context as we use them ourselves.
Packages from `pkgs/default.nix` are meant to be exposed to all nixos
configurations. However, #61 removed a redundancy in the output api
which was relied up to do so.
