prior to this commit the bootstrapping iso deactivated _all_ profiles
that were somehow contained in a suite.
that is an error, since it deactivates all profiles, even the most basic
and desired ones.
the impetus had been to prevent unwantes systemd services from launching
however, there seems no reliable approach to achieve that.
the now proposed alternative model is to add a bootsrap host akin to
the followint config:
```nix
# os/hosts/bootstrap.nix
{ profiles, ... }:
{
imports = [
profiles.networking
profiles.users.root
profiles.users.nixos
];
}
```
this allow users to specifiy per hosts tests in the host api container
under `.test`.
test must be an attrs or a function that is invoked as a package and
that returns an attrs which can be consumed by nixos' `mkTest`.
tests must have a name, so that they can be told apart in the
flake's check attribue.
portable home manager configs are derived from the default channel's
`pkgs`, however host speific home manager configs, obviously remain
derived from the respective host's `pkgs`, which can be based on a
different channel.
There was never an intention to setup the registry with aliases, which
would not avoid a network call ayhow if an input is not specified as an
registry-resolvable input.
At the same time, this clarification also eliniates an error that is
addressed upstream via https://github.com/NixOS/nixpkgs/pull/131814
---
work-around: for spurious reasons w.r.t. functor attrs in module system
Without any obvious reason, the module system appears to substitute
attrs that contain a `__functor` with the value of that functor.
for example: error: Package ‘zfs-kernel-2.0.5-5.13.4’ in /nix/store/jbch90yqx6gg1h3fq30jjj2b6h6jfjgs-source/pkgs/os-specific/linux/zfs/default.nix:175 is marked as broken, refusing to evaluate.
`self` and `inputs` might have library functions or other features that
users want to use within the module system.
To avoid infinite recursion when used within the context of `imports`
statements, make them `sepcialArgs`.
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`.
