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.
This is necesary since `fup` has gained a cleanup of its module exporter
that treats modules as paths or well-defeinde (with _file).
This is a better implementation for the work-around introduced in
b30d9660e2903e08bb10bea9921eee119af0b111
