foodogsquared/nixos-config
1
0
Fork 0
mirror of https://github.com/foo-dogsquared/nixos-config.git synced 2025-02-07 18:19:09 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

docs: remove relevant sections to custom check variables

Browse Source
This commit is contained in:
Gabriel Arazas 2024-01-07 17:34:29 +08:00
parent 72ba0b9028
commit 4f286dbc28
No known key found for this signature in database
GPG Key ID: ADE0C41DAB221FCC
1 changed files with 3 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
modules/nixos/profiles/README.adoc
View File

@ -1,6 +1,5 @@
= Profiles = Profiles
:toc: :toc:
:check_variable: _isfoodogsquaredcustom
We're defining profiles after how link:https://digga.divnix.com/concepts/profiles.html[digga library from divnix defines it]. We're defining profiles after how link:https://digga.divnix.com/concepts/profiles.html[digga library from divnix defines it].
@ -30,41 +29,7 @@ As future reference, here's an exhaustive list of namespaces you should avoid us
* `services` and `programs` shouldn't use any profiles at all since they are small in scope that they are more likely to be combined with other modules. * `services` and `programs` shouldn't use any profiles at all since they are small in scope that they are more likely to be combined with other modules.
* Any modules under `workflows` are not exactly prohibited to use profiles since they are all-encompassing modules that creates a desktop that may be composed of multiple modules. * Workflow modules (`workflows`) are prohibited to use profiles to discourage very customized configurations that are otherwise more suitable in the host, user, etc.
However, it is heavily discouraged. We have host- and user-specific modules for those purpose.
If used, be sure to put it under a check with `{check_variable}` which is an extra argument passed to various profiles (e.g., NixOS, home-manager) as an optional part of the configuration.
Take note that workflows are also exported in the flake output.
footnote:[Overall, I don't think it's not much of a threat to set profiles in the workflow unless users that is not me have conspicuously similar setup to mine. It's just discouraged to minimize stepping on as less as configurations as possible.]
* Really, anything that is being exported in the flake outputs (i.e., look for the attributes in `nix flake show`) unless explicitly stated like the case for `workflows`. * Really, anything that is being exported in the flake outputs (i.e., look for the attributes in `nix flake show`).
== Setting profiles conditionally
Because the way how profiles are exported in the flakes (which is not at all), we cannot easily export modules that make use of them.
For this, we have the `{check_variable}` attribute passed as part of `specialArgs` (or something similar) to the NixOS configuration.
The attribute is a boolean value and only used for checking if it's going to be included as part of the holistic system.
Take note it should be only enabled in this flake, outsiders shouldn't set this variable in any way.
Here's one way how to do it as shown in the following snippet of a NixOS module.
[source, nix, subs=attributes]
----
{ config, options, pkgs, lib, ... }@attrs:
{
# ...
config = lib.mkIf cfg.enable (lib.mkMerge [
{
# Some required parts here.
}
(lib.mkIf (attrs ? {check_variable} && attrs.{check_variable}) {
# Set profiles here.
})
];
}
----