Users may not have setup their nix correctly. This ensures they have the
proper features and caches setup when they use this repo.
We currently have not entire clarity wether all `nixConig` flake options
work. At some point in time `nix` support was limited.
Therefore, we implement an NIX_CONFIG fallback (at least) in the devshell
supersedes #69
It is very likely that some digga functionality requires patches to nix
Create a place for patches that mimicks the way how they could be
applied once `inputs.<name>.patches` of the
UFR (Unofficial Flakes Roadmap) is implemented.
Also showcase how `nixConfig` can add extra feature flags (without
overriding the patched-in ones).
When using the `user@host` idiom, we explicitly want to deploy that
users on that host. Therefore, don't alter the deployment
configuration between the method that uses `homeConfigurations` and
the method that changes the home configuration as part of the system
configuration change.
In the future a portable `user/arch` combination can be implemented.
Such `user/arch` is not host specific and can be deployed to any host
where nix is installed (e.g. at work). In this use case, we have to
make sure that the user's $HOME/.nix-profile is used as the profile,
that is `home-manager.useUserPackages = mkForce false`.
Without this modification to the initial implementation, we this error:
```console
error: attribute 'activationPackage' missing
at /nix/store/2ja93yb8276wk794zkgnaf0m5rghp5mw-source/src/mkFlake/default.nix:145:37:
144| ) then
145| lib.mapAttrs (n: v: v.activationPackage) self.homeConfigurations
| ^
146| else { }
```
`submoduleWith` does not have the `_module` options, so the only two
options left are passing via `specialArgs` or create a self option
to pass it as config. For better UX, let's use specialArgs, here.
In this changeset, the `self` module argument is not actually passed.
Upstream nixpkgs, for unknown reasons does not fail with the usual
error message, presumably becuase this is sumoduleWith type, but instead
bails with an inifinite recursion.
in order to avoid people accidentially depending on some internal API
which we don't explicitly want to support well into version 1.0, hide
those from the output.
Users who still want to use those need to copy them over, instead.
This reduces our API exposure and hopefully will help save maintainer
resources once `digga` completely takes over the world.
