mirror of
https://github.com/foo-dogsquared/nixos-config.git
synced 2025-02-07 12:19:07 +00:00
docs/site: write "NixOS modules" chapter
This commit is contained in:
parent
75218992de
commit
cd4bc63cb7
@ -13,8 +13,8 @@
|
|||||||
** link:{{< relref "./project-specific-setup/custom-firefox-addons" >}}[Custom Firefox addons]
|
** link:{{< relref "./project-specific-setup/custom-firefox-addons" >}}[Custom Firefox addons]
|
||||||
|
|
||||||
* NixOS modules
|
* NixOS modules
|
||||||
** link:./nixos-modules/profiles[Profiles]
|
** link:{{< relref "./nixos-modules/profiles" >}}[Profiles]
|
||||||
** link:./nixos-modules/workflows[Workflows]
|
** link:{{< relref "./nixos-modules/workflows" >}}[Workflows]
|
||||||
|
|
||||||
* link:{{< relref "./using-parts-of-my-configuration" >}}[Using parts of my configuration]
|
* link:{{< relref "./using-parts-of-my-configuration" >}}[Using parts of my configuration]
|
||||||
|
|
||||||
|
57
docs/content/en-US/nixos-modules/profiles/index.adoc
Normal file
57
docs/content/en-US/nixos-modules/profiles/index.adoc
Normal file
@ -0,0 +1,57 @@
|
|||||||
|
---
|
||||||
|
title: Profiles
|
||||||
|
---
|
||||||
|
= Profiles
|
||||||
|
|
||||||
|
In my github:{github-repo}[NixOS modules, path=./modules/nixos, rev=master], there is a subset of modules for profiles.
|
||||||
|
The way we defined profiles is very similar to digga profiles.
|
||||||
|
|
||||||
|
[quote, digga library]
|
||||||
|
____
|
||||||
|
Profiles are a convenient shorthand for the definition of options in contrast to their declaration.
|
||||||
|
They're built into the NixOS module system for a reason: to elegantly provide a clear separation of concerns.
|
||||||
|
____
|
||||||
|
|
||||||
|
Except the difference is we also included a declaration for setting those options.
|
||||||
|
This enables different modules in our NixOS configurations to set those up in different points in time without getting a duplicate value error which is nice.
|
||||||
|
However, enabling profiles shouldn't be taken lightly.
|
||||||
|
In my project, the situations to enable profiles are limited.
|
||||||
|
|
||||||
|
Here are the module namespaces with their guidelines for setting them profiles.
|
||||||
|
|
||||||
|
* `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.]
|
||||||
|
|
||||||
|
* 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`.
|
||||||
|
|
||||||
|
[chat, Ezran, state=curious, role=reversed]
|
||||||
|
====
|
||||||
|
Son, just like what I keep telling you: is this solution good enough?
|
||||||
|
====
|
||||||
|
|
||||||
|
[chat, foodogsquared]
|
||||||
|
====
|
||||||
|
For the most part, yeah.
|
||||||
|
But the way how I'm using profiles is pretty similar to digga profiles in the same way that it is really used only once at most point.
|
||||||
|
====
|
||||||
|
|
||||||
|
[chat, Ezran, role=reversed]
|
||||||
|
====
|
||||||
|
Why don't you use digga then?
|
||||||
|
====
|
||||||
|
|
||||||
|
[chat, foodogsquared]
|
||||||
|
====
|
||||||
|
digga github:divnix/digga[was considered to be a dead project, issue=503] which is unfortunate.
|
||||||
|
When I was grokking flakes, I used their example extensively and eventually understood a lot about flakes and Nix modules overall.
|
||||||
|
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].
|
||||||
|
====
|
||||||
|
|
||||||
|
Also take note, you'll see similar home-manager profile modules around in my project.
|
||||||
|
They're pretty much the same as defined here except that they're home-manager modules.
|
38
docs/content/en-US/nixos-modules/workflows/index.adoc
Normal file
38
docs/content/en-US/nixos-modules/workflows/index.adoc
Normal file
@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: Workflows
|
||||||
|
---
|
||||||
|
= Workflows
|
||||||
|
|
||||||
|
Workflows are an all-encompassing NixOS module 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 or your dolled up standalone window manager setup.
|
||||||
|
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.
|
||||||
|
|
||||||
|
[source, nix]
|
||||||
|
----
|
||||||
|
{ config, lib, pkgs, ... }:
|
||||||
|
|
||||||
|
{
|
||||||
|
workflows.workflows.a-happy-gnome.enable = true;
|
||||||
|
}
|
||||||
|
----
|
||||||
|
|
||||||
|
Take note you cannot enable more than two workflows at any given time.
|
||||||
|
|
||||||
|
[source, nix]
|
||||||
|
----
|
||||||
|
{ config, lib, pkgs, ... }:
|
||||||
|
|
||||||
|
{
|
||||||
|
# This would cause an assertion error.
|
||||||
|
workflows.workflows = {
|
||||||
|
a-happy-gnome.enable = true;
|
||||||
|
knome.enable = true;
|
||||||
|
};
|
||||||
|
}
|
||||||
|
----
|
||||||
|
|
||||||
|
You can get around this by setting `workflows.disableLimit` to `true`.
|
||||||
|
However, this shouldn't be taken lightly as workflow modules are very vast in scope and are expected to set system settings that can affect your hardware, enabling (and/or disabling) system services, and modifying the list of installed applications (among other things).
|
Loading…
Reference in New Issue
Block a user