foodogsquared/nixos-config
1
0
Fork 0
mirror of https://github.com/foo-dogsquared/nixos-config.git synced 2025-01-31 04:58:01 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

docs/site: update sections since removal of check variable

Browse Source
This commit is contained in:
Gabriel Arazas 2024-01-04 12:03:29 +08:00
parent 55a3ea8390
commit 42c542fa01
No known key found for this signature in database
GPG Key ID: ADE0C41DAB221FCC
3 changed files with 13 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/config/_default/markup.toml
View File

@ -27,7 +27,6 @@ icontype = "svg"
# Project-wide attributes to be used.
github-repo = "foo-dogsquared/nixos-config"
check-variable = "_isfoodogsquaredcustom"
canonical-flake-url = "github:foo-dogsquared/nixos-config"
canonical-source-repo = "https://github.com/foo-dogsquared/nixos-config"
canonical-flake-url-tarball-master = "https://github.com/foo-dogsquared/nixos-config/archive/master.tar.gz"

47
docs/content/en-US/04-nixos-modules/01-profiles/index.adoc
View File

@ -30,11 +30,8 @@ Here are the module namespaces with their guidelines for setting them profiles.
[#lst:profile-namespace-guidelines]
* `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.
However, it is heavily discouraged.
If used, be sure to put it under a check with `{check-variable}` which is an extra argument passed to various environments (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.]
* Workflow modules (`workflows`) are prohibited to use profiles to discourage very customized configurations that are otherwise more suitable in the host, user, etc.
We have host- and user-specific modules for those purpose.
* 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`.
@ -61,43 +58,3 @@ When I was grokking flakes, I used their example extensively and eventually unde
But the project is really big and overwhelming to use it for someone who only started using flakes so I just went through the project piece by piece and only used a small subset of it.
I think link:https://github.com/divnix/digga/issues/503#issuecomment-1546359287[this comment sums up the problems of the project].
====
== Setting profiles conditionally
In case of making modules that are intended to be used somewhere else but also needing a part of my profiles to be applied, there are ways to get around this.
The main way is through checking a certain variable, `{check-variable}`, which is intended for this configuration and only for this configuration.
As noted from the <<lst:profile-namespace-guidelines, guidelines>>, this is mainly used for certain types of modules such as the xref:../02-workflows/index.adoc[workflow modules] where it is used by me as well as (potentially) by others.
Here's a snippet of conditionally setting a profile within the 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.
})
];
}
----
[chat, Ezran, role=reversed]
====
Why not just set a separate module that contains all of the setup-specific checks with their settings?
====
[chat, foodogsquared]
====
Convenience and better organization.
But yeah, ideally these checks should be in a separate module especially for workflow modules at the cost of organization (and also needing to update it separately since it's on a separate file).
====

16
docs/content/en-US/04-nixos-modules/02-workflows/index.adoc
View File

@ -3,12 +3,12 @@ title: Workflows
---
= Workflows
Workflows are an all-encompassing NixOS module for dictating how you interact with your computer/device/whatever.
Workflows are all-encompassing NixOS modules for dictating how you interact with your computer/device/whatever.
Basically, this is where certain things are set such as your GNOME desktop environment settings, your dolled up standalone window manager setup, or an oddball audio-only desktop interface.
They are located in `./nixos/modules/workflows` at the project root.
Workflows are defined under the namespace `workflows` where each workflow module is set to be declared and to be enabled at `workflows.workflows.<name>`.
For example, here's how I would enable my (hypothetical) GNOME desktop workflow.
Workflows are defined under the namespace `workflows` where each workflow module is set to be declared and to be enabled at `workflows.workflows.<name>.enable`.
For example, here's how I would enable my imaginary GNOME desktop workflow.
[source, nix]
----
@ -39,7 +39,7 @@ However, this shouldn't be taken lightly as workflow modules are very vast in sc
* Enabling (and/or disabling) system services such as the preferred network manager.
* Modifying the list of installed applications.
* Setting up programs with custom configurations which could cause conflicts with the defaults (upstream or from nixpkgs).
* Setting up programs with custom configurations which could cause conflicts with the defaults (upstream or from nixpkgs) or with another workflow module.
[chat, foodogsquared]
====
@ -57,14 +57,20 @@ Whether those rices are worth posting to Unix ricing communities is up to you th
Whippersnappers with your "riced"-up systems...
====
== Designing a workflow module
There are a few guidelines to designing a workflow module which is already laid out in its respective README but as a reminder, let's list it here.
* All workflow modules should be under `workflows.workflows.<name>` namespace with an `enable` option.
* No usage of the private modules.
It is a public module, after all so it'll make things messier.
While we can conditionally set the configuration, it is pretty useless since we have the host-specific module structure.
While we can conditionally set the configuration, it is pretty useless since we have the xref:../03-disko/index.adoc[host-specific module structure].
* No locale-related settings.
Each user may have its own set of preferred locales and their setup so it is pretty much prohibited from setting any.
The only related parts a workflow module can set is their preferred input method engine (IME) of choice.
The rest of the locale settings is best configured from the host or its individual users.