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: update

Browse Source
This commit is contained in:
Gabriel Arazas 2022-11-12 10:37:17 +08:00
parent 5643321759
commit 9cb4e335e0
4 changed files with 11 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -43,9 +43,14 @@ footnote:[Overall, I don't think it's not much of a threat to set profiles in th
== Setting profiles conditionally == Setting profiles conditionally
The following snippet of a NixOS module with an optional part check with the simple boolean variable. 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.
[subs=attributes, source, nix] 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, options, pkgs, lib, ... }@attrs:
@ -63,6 +68,3 @@ The following snippet of a NixOS module with an optional part check with the sim
]; ];
} }
---- ----
So yeah... have at it.
This is useful for setting profiles inside of modules that are otherwise not possible to easily export for others' use (e.g., `workflows`).

5
modules/nixos/workflows/README.adoc
View File

@ -2,7 +2,7 @@
:toc: :toc:
These are where my workflows are defined and configured. These are where my workflows are defined and configured.
Basically, workflows are mainly graphical sessions concerned with aesthetics, this may include Unix rices and good 'ol reliable desktop configurations like my link:./a-happy-gnome[GNOME config]. Basically, workflows are mainly graphical sessions concerned with aesthetics and impose a structured way of using things, this may include Unix rices and good 'ol reliable desktop configurations like my link:./a-happy-gnome[GNOME config].
This is where modules will define how you're going to interact with the computer whether you should use something ranging from a full-fledged desktop environment with bells and whistles to a minimalist desktop environment only composing of a window manager, a terminal, and a bar. This is where modules will define how you're going to interact with the computer whether you should use something ranging from a full-fledged desktop environment with bells and whistles to a minimalist desktop environment only composing of a window manager, a terminal, and a bar.
The following list is the summary which can also serve as a guideline to developing a workflow module. The following list is the summary which can also serve as a guideline to developing a workflow module.
@ -15,5 +15,4 @@ This makes up for a namespace entirely dedicated for setting themes.
* Using link:../profiles[profiles] are heavily discouraged and it is better assumed to design and create workflows as if profiles are not imported. * Using link:../profiles[profiles] are heavily discouraged and it is better assumed to design and create workflows as if profiles are not imported.
This is because profiles are not exported in the flake output. This is because profiles are not exported in the flake output.
Thus, any part of the workflow configuration using profiles will not be properly used due to the missing modules. If it's something you have to use (e.g., setting up i18n configuration), you have to conditionally set a profile as seen from link:../profiles/README.adoc[../profiles/README.adoc].
If it's something you have to use (e.g., setting up i18n configuration), you have to explicitly import them through the `imports` attribute to make it work.

5
modules/nixos/workflows/a-happy-gnome/README.adoc
View File

@ -5,7 +5,4 @@
image::./assets/a-happy-gnome-dirty.png[GNOME Shell with the Settings application, width=100%,height=100%] image::./assets/a-happy-gnome-dirty.png[GNOME Shell with the Settings application, width=100%,height=100%]
Yes, it's a theme that configures GNOME. Yes, it's a theme that configures GNOME.
I mostly want a usable GNOME environment out-of-the-box (with my modifications and whatnot). I mostly want a usable GNOME environment out-of-the-box (with my modifications and whatnot) including a bunch of applications, GNOME extensions, and other core services.
Among others, it has `chrome-gnome-shell` out of convenience provided you have a browser installed.
A couple of extensions such as ArcMenu and what not.

2
users/README.adoc
View File

@ -35,4 +35,4 @@ This includes user-specific packages, home-manager-specific configuration footno
If you want to set users from the host, see link:../hosts/README.adoc[Host-specific configurations] for more details. If you want to set users from the host, see link:../hosts/README.adoc[Host-specific configurations] for more details.
* home-manager users are just home-manager configurations (i.e., `$XDG_CONFIG_HOME/nix/home.nix`). * home-manager users are just home-manager configurations (i.e., `$XDG_CONFIG_HOME/nix/home.nix`).
That's pretty much it. Take note that it is assumed that my link:../modules/home-manager/[own home-manager modules] are imported.