rexport profiles as integration modules

[nrdxp]

Ideas, Requests, etc...
Profiles can be written in such a way as to abstract information into a (mostly) semantically equivolent modules for both home-manager and devshell (and darwin once #34 is resolved). Let's do it, so we can deploy our expressions everywhere! This will finally put #38 to rest.

Update
I've worked out a minimal implementation for static configuration files. Sander has made teriffic progress on svanderburg/nix-processmgmt on cross compatible services which we can integrated at a later time, and there is an open RFC to modify the way modules are declared to allow for easier cross pollination, but I was also wanting a solution that leverages the existing NixOS modules in nixpkgs, unmodified, since this project is, after all, meant as an entry point to NixOS. New users may not wish to declare all their own modules from scratch, I know I certainly don't want to.

In order for that to be truly convenient however, users will need their nix expressions to be accessible from any system they use, since they won't always have the luxury of using NixOS.

There are essentially two concerns when dealing with static configuration of a NixOS system:

1. Files is the environment: environment.etc
2. Environmental variables: environment.sessionVariables

On an ad hoc basis, I've already gotten my zshrc file, completely unmodified set in the proper place via a home manager module and it worked tremendously. I played around in the repl earlier and was able to read the config contents of a NixOS module, and extract which values of etc and sessionVariables are actually modified, and then pulled them from the final config.

This allows users to still declare their configuration in high level module options like programs.zsh, and extract out the end result, which is simply some files and variables placed in the environment, simple to replicate in another target.

With some careful attention, we could evaluate the module in isolation to ensure unwanted modifications don't leak in. We could then use those artifacts from etc and sessionVariables to then place the files in the expected places for various projects. nix-darwin is an exceptional straight shot as environment.etc and environment.variables exists as essentially clones of the NixOS equivalents.

So in theory, by restricting the implementation to these two concerns, we should be able to offer a fairly comprehensive converage of at least the static bits of configuration scattered throughout nixpkgs existing NixOS modules. To actually implement this, we will need to finalize the repository structure, as the current _hosts/default.nix` restricts easy inegration of nix-darwin, and possible simplification of home-manager integration. #152

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[nrdxp]

Since the beginning of the project, I've been wanting to add a layer of dhall somewhere sensible, but not without purpose.

It seems like abstract modules may benefit from some type constraints, and the static nature of configuration data may make this the perfect layer for dhall to improve our experience.

[jorsn]

Why not declare profiles nixos options in a module like this

{ lib, ... }:
let
  profile = with lib; mkOptionType {
    name = "profile";
    description = "module not declaring options";
    check = types.submodule.check && ! hasAttr "options";
    merge = mergeOneOption; # we want profiles to be unique, not merged
  };
in {
  options.profiles = lib.mkOption {
    type = types.attrsOf profile;
    description = "modules not declaring options";
    default = {};
  };
}

and maybe add a function to convert the attr paths between different applications (home-manager, dev-shell, ...)? This could be done with suites as well (type = listOf profile).

This would be simpler to understand than dhall (another language + type system), albeit simplicity clearly not being the primary concern of this project compared to cool magic.

[nrdxp]

Well I was considering using dhall internally, to add some type constraints, it would be hidden from the user. It was just an idea at this point though.

[nrdxp]

For those following the issue, I've updated the original post with implementation details.

[Pacman99]

With the APIv1 context I wonder if this should only be done internally in lib.modules or if there should be some API support for it. In the current version of the API you can only pass modules and profiles to nixos or home. So maybe we could add a top-level genericProfiles argument.
But I guess the first goal would be to make use of lib.modules and see how well it can be done there in the internal devos modules.