mirror of
https://github.com/moons-14/dotfiles.git
synced 2026-10-06 04:08:12 +09:00
feat
This commit is contained in:
+6
-6
@@ -19,9 +19,9 @@
|
|||||||
!/flake/
|
!/flake/
|
||||||
!/overlays/
|
!/overlays/
|
||||||
|
|
||||||
!/modules/applications/
|
!/images/
|
||||||
!/modules/hardwares/
|
!/secrets/
|
||||||
!/modules/profiles/
|
|
||||||
!/modules/services/
|
!/hosts/
|
||||||
!/modules/systems/
|
|
||||||
!/modules/users/
|
!/modules/
|
||||||
|
|||||||
@@ -1,28 +1,574 @@
|
|||||||
# Repository Guidelines
|
# Repository Guidelines
|
||||||
|
|
||||||
## Project Structure & Module Organization
|
## Project Structure and Ownership
|
||||||
|
|
||||||
This repository manages NixOS and Home Manager configuration as a flake. `flake.nix` defines inputs and imports the project modules. Keep flake-level plumbing in `flake/`, reusable package overlays in `overlays/`, and development environments in `shells/`. Add configuration under the appropriate `modules/` category: `applications/`, `hardwares/`, `profiles/`, `services/`, `systems/`, or `users/`. Keep host- or user-specific choices near their owning module rather than in the root flake.
|
This repository manages NixOS, nix-darwin, and Home Manager configurations as a
|
||||||
|
flake. `flake.nix` defines inputs and delegates flake outputs through
|
||||||
|
flake-parts. Keep configuration with the component that owns it, rather than in
|
||||||
|
the root flake or an unrelated host.
|
||||||
|
|
||||||
|
| Path | Responsibility |
|
||||||
|
| ----------------------- | ----------------------------------------------------------------------------------------------------------------- |
|
||||||
|
| `modules/applications/` | One software component, including GUI applications, window managers, desktop environments, CLI tools, and editors |
|
||||||
|
| `modules/systems/` | OS foundations such as Nix, boot, locale, Wayland, and networking |
|
||||||
|
| `modules/services/` | Daemons, long-running services, and configuration that involves permissions or user groups |
|
||||||
|
| `modules/hardwares/` | Reusable drivers, hardware families, and VM or WSL guest configuration |
|
||||||
|
| `modules/users/` | User identity and the user's NixOS-, nix-darwin-, and Home Manager-specific definitions |
|
||||||
|
| `modules/profiles/` | Purpose- or form-factor-oriented compositions of multiple units |
|
||||||
|
| `hosts/` | Machine-specific facts and the profiles or applications selected for each machine |
|
||||||
|
| `libs/` | Registry, unit discovery, and host construction logic |
|
||||||
|
| `overlays/` | Package replacements and additions |
|
||||||
|
| `shells/` | Development shells |
|
||||||
|
| `flake/` | Supporting flake outputs such as formatters, checks, and Git hooks |
|
||||||
|
|
||||||
|
Use **unit** as the generic internal term for a Registry-managed component and
|
||||||
|
**profile** for a unit that composes multiple units. Do not introduce a
|
||||||
|
`features/` layer. Window managers and desktop environments such as niri and
|
||||||
|
GNOME belong in `modules/applications/`; do not create a separate `desktop/`
|
||||||
|
module category.
|
||||||
|
|
||||||
|
Before adding configuration, decide whether it is owned by an application,
|
||||||
|
system foundation, service, hardware family, user, profile, or individual host.
|
||||||
|
Prefer the following placements:
|
||||||
|
|
||||||
|
| Configuration | Placement |
|
||||||
|
| ---------------------------------------------------- | ------------------------------------------------ |
|
||||||
|
| Nix settings shared by every system host | `modules/systems/nix/common.nix` |
|
||||||
|
| NixOS-only boot configuration | `modules/systems/boot/.../nixos.nix` |
|
||||||
|
| Ghostty-specific configuration | `modules/applications/ghostty/` |
|
||||||
|
| niri-specific configuration | `modules/applications/niri/` |
|
||||||
|
| Applications selected for the niri environment | `modules/profiles/interface/niri/meta.nix` |
|
||||||
|
| GNOME itself | `modules/applications/gnome/` |
|
||||||
|
| Docker daemon and Docker group membership | `modules/services/docker/nixos.nix` |
|
||||||
|
| Reusable ThinkPad-family configuration | `modules/hardwares/thinkpad/` |
|
||||||
|
| The laptop unit composition | `modules/profiles/platform/laptop/meta.nix` |
|
||||||
|
| The development-environment unit composition | `modules/profiles/workload/development/meta.nix` |
|
||||||
|
| A user's OS- and Home Manager-specific configuration | `modules/users/<name>/` |
|
||||||
|
| x1g13-specific monitor layout | `hosts/x1g13/home.nix` |
|
||||||
|
| x1g13-specific disk UUID | `hosts/x1g13/nixos.nix` |
|
||||||
|
| Package replacement or addition | `overlays/` |
|
||||||
|
| Formatter, checks, or Git hooks | `flake/` |
|
||||||
|
|
||||||
|
## Unit Discovery and Identity
|
||||||
|
|
||||||
|
A directory below `modules/` is a unit if, and only if, it directly contains at
|
||||||
|
least one reserved file. Directories used only for classification, such as
|
||||||
|
`modules/applications/` or `modules/profiles/interface/`, are namespaces rather
|
||||||
|
than units when they have no reserved file of their own.
|
||||||
|
|
||||||
|
The Registry recognizes exactly these five reserved filenames:
|
||||||
|
|
||||||
|
| File | Target and responsibility |
|
||||||
|
| ------------ | -------------------------------------------------------------------------------- |
|
||||||
|
| `common.nix` | System-side configuration fragment shared by NixOS and nix-darwin |
|
||||||
|
| `nixos.nix` | NixOS-only configuration fragment |
|
||||||
|
| `darwin.nix` | nix-darwin-only configuration fragment |
|
||||||
|
| `home.nix` | Home Manager configuration fragment |
|
||||||
|
| `meta.nix` | Registry descriptor for dependencies, external modules, and descriptive metadata |
|
||||||
|
|
||||||
|
`common.nix` is never applied to Home Manager. OS-independent Home Manager
|
||||||
|
configuration still belongs in `home.nix`.
|
||||||
|
|
||||||
|
The Registry derives a unit ID from the path relative to `modules/`, joining
|
||||||
|
path components with dots. Category names remain plural. It also derives the
|
||||||
|
enable option by prefixing the same components with `my` and appending `enable`.
|
||||||
|
|
||||||
|
| Unit directory | Unit ID | Enable option |
|
||||||
|
| ---------------------------------- | ------------------------- | ----------------------------------- |
|
||||||
|
| `modules/applications/ghostty/` | `applications.ghostty` | `my.applications.ghostty.enable` |
|
||||||
|
| `modules/applications/niri/` | `applications.niri` | `my.applications.niri.enable` |
|
||||||
|
| `modules/systems/boot/uefi/` | `systems.boot.uefi` | `my.systems.boot.uefi.enable` |
|
||||||
|
| `modules/services/docker/` | `services.docker` | `my.services.docker.enable` |
|
||||||
|
| `modules/hardwares/qemu-guest/` | `hardwares.qemu-guest` | `my.hardwares.qemu-guest.enable` |
|
||||||
|
| `modules/users/moons/` | `users.moons` | `my.users.moons.enable` |
|
||||||
|
| `modules/profiles/interface/niri/` | `profiles.interface.niri` | `my.profiles.interface.niri.enable` |
|
||||||
|
|
||||||
|
Represent option paths as attribute-path lists, never as Nix source encoded in
|
||||||
|
strings or evaluated dynamically. Generate and read attributes with helpers such
|
||||||
|
as `lib.setAttrByPath` and `lib.getAttrFromPath`:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
{
|
||||||
|
id = "applications.ghostty";
|
||||||
|
|
||||||
|
optionPath = [
|
||||||
|
"my"
|
||||||
|
"applications"
|
||||||
|
"ghostty"
|
||||||
|
"enable"
|
||||||
|
];
|
||||||
|
|
||||||
|
kind = "applications";
|
||||||
|
name = "ghostty";
|
||||||
|
|
||||||
|
relativePath = [
|
||||||
|
"applications"
|
||||||
|
"ghostty"
|
||||||
|
];
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
For `modules/profiles/interface/niri/`, path inference additionally gives
|
||||||
|
`kind = "profiles"`, `group = "interface"`, and `name = "niri"`. The path is
|
||||||
|
always authoritative for identity. `meta.nix` may provide display metadata such
|
||||||
|
as `description`, but it must not override or alias the unit ID.
|
||||||
|
|
||||||
|
## Unit Files and Fragment Contract
|
||||||
|
|
||||||
|
Only reserved files that a unit actually needs should exist. The Registry
|
||||||
|
registers present fragments and does not require empty or placeholder files. All
|
||||||
|
of the following are valid units:
|
||||||
|
|
||||||
|
```text
|
||||||
|
# Home Manager only
|
||||||
|
modules/applications/ghostty/
|
||||||
|
├── home.nix
|
||||||
|
└── settings.nix
|
||||||
|
|
||||||
|
# NixOS only
|
||||||
|
modules/applications/gnome/
|
||||||
|
└── nixos.nix
|
||||||
|
|
||||||
|
# nix-darwin only
|
||||||
|
modules/systems/macos-defaults/
|
||||||
|
└── darwin.nix
|
||||||
|
|
||||||
|
# NixOS and Home Manager, with metadata and helpers
|
||||||
|
modules/applications/niri/
|
||||||
|
├── nixos.nix
|
||||||
|
├── home.nix
|
||||||
|
├── meta.nix
|
||||||
|
├── settings.nix
|
||||||
|
└── keybindings.nix
|
||||||
|
|
||||||
|
# Metadata only, commonly a composition profile
|
||||||
|
modules/profiles/interface/niri/
|
||||||
|
└── meta.nix
|
||||||
|
|
||||||
|
# System configuration shared by NixOS and nix-darwin
|
||||||
|
modules/systems/nix/
|
||||||
|
└── common.nix
|
||||||
|
```
|
||||||
|
|
||||||
|
If a unit has no `home.nix`, do not generate or apply a Home Manager module for
|
||||||
|
it. The same rule applies independently to `common.nix`, `nixos.nix`, and
|
||||||
|
`darwin.nix`.
|
||||||
|
|
||||||
|
### Configuration fragments
|
||||||
|
|
||||||
|
`common.nix`, `nixos.nix`, `darwin.nix`, and `home.nix` are configuration
|
||||||
|
fragments to which the Registry adds the enable condition. They return the
|
||||||
|
configuration for their class directly and must not define top-level `imports`,
|
||||||
|
`options`, or `config` attributes:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
# modules/services/docker/nixos.nix
|
||||||
|
{ primaryUser, ... }:
|
||||||
|
{
|
||||||
|
virtualisation.docker = {
|
||||||
|
enable = true;
|
||||||
|
autoPrune.enable = true;
|
||||||
|
};
|
||||||
|
|
||||||
|
users.users.${primaryUser}.extraGroups = [
|
||||||
|
"docker"
|
||||||
|
];
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Conceptually, the Registry supplies a wrapper like this:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
{ config, lib, ... }@args:
|
||||||
|
{
|
||||||
|
config =
|
||||||
|
lib.mkIf
|
||||||
|
config.my.services.docker.enable
|
||||||
|
(import dockerNixosPath args);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Do not add hand-written `mkEnableOption`, `cfg`, or `mkIf` boilerplate to each
|
||||||
|
unit. The Registry generates the enable option from the unit path and guards the
|
||||||
|
fragment.
|
||||||
|
|
||||||
|
### Helper files and directories
|
||||||
|
|
||||||
|
Every filename other than the five reserved names is an ordinary helper,
|
||||||
|
regardless of its extension. The Registry neither discovers nor automatically
|
||||||
|
imports helper files such as `settings.nix`, `keybindings.nix`, `packages.nix`,
|
||||||
|
`colors.nix`, `rules.nix`, or `helpers.nix`. Import a helper explicitly from the
|
||||||
|
reserved fragment that uses it:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
# modules/applications/niri/home.nix
|
||||||
|
{ lib, ... }:
|
||||||
|
let
|
||||||
|
settings = import ./settings.nix;
|
||||||
|
keybindings = import ./keybindings.nix;
|
||||||
|
in
|
||||||
|
{
|
||||||
|
programs.niri.settings = lib.recursiveUpdate settings {
|
||||||
|
binds = keybindings;
|
||||||
|
};
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Do not use a leading underscore to mark a file private; `_settings.nix` has no
|
||||||
|
special meaning. Give helper files descriptive names instead. When helpers are
|
||||||
|
configuration functions, pass the module arguments explicitly and combine them
|
||||||
|
with normal Nix expressions:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
# modules/applications/example/home.nix
|
||||||
|
{ lib, ... }@args:
|
||||||
|
lib.mkMerge [
|
||||||
|
(import ./packages.nix args)
|
||||||
|
(import ./settings.nix args)
|
||||||
|
]
|
||||||
|
```
|
||||||
|
|
||||||
|
The same discovery rule applies recursively to helper directories:
|
||||||
|
|
||||||
|
```text
|
||||||
|
modules/applications/niri/
|
||||||
|
├── home.nix
|
||||||
|
└── parts/
|
||||||
|
├── appearance.nix
|
||||||
|
└── keybindings.nix
|
||||||
|
```
|
||||||
|
|
||||||
|
Here `parts/` is not a unit because it directly contains no reserved file. A
|
||||||
|
helper directory that directly contains `home.nix` or another reserved file is
|
||||||
|
itself discovered as a unit, so never use reserved filenames inside a directory
|
||||||
|
that is intended to contain helpers only.
|
||||||
|
|
||||||
|
### Registry metadata
|
||||||
|
|
||||||
|
`meta.nix` is a Registry descriptor, not a NixOS, nix-darwin, or Home Manager
|
||||||
|
module. It may declare `description`, `includes`, and class-specific external
|
||||||
|
module imports:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
# modules/applications/niri/meta.nix
|
||||||
|
{ inputs, ... }:
|
||||||
|
{
|
||||||
|
description = "Niri Wayland compositor";
|
||||||
|
|
||||||
|
includes = [
|
||||||
|
"systems.wayland"
|
||||||
|
"services.xdg-portal"
|
||||||
|
];
|
||||||
|
|
||||||
|
imports.nixos = [
|
||||||
|
inputs.niri-flake.nixosModules.niri
|
||||||
|
];
|
||||||
|
|
||||||
|
imports.home = [
|
||||||
|
inputs.niri-flake.homeModules.niri
|
||||||
|
];
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
External modules, including modules supplied by flake inputs, define Nix module
|
||||||
|
options and therefore belong in `meta.nix` under `imports.nixos`,
|
||||||
|
`imports.darwin`, or `imports.home`. Do not place them in a configuration
|
||||||
|
fragment's top-level `imports`: the Nix module system resolves imports before a
|
||||||
|
configuration-level enable condition.
|
||||||
|
|
||||||
|
`includes` lists units to enable whenever the declaring unit is enabled. Always
|
||||||
|
use fully qualified unit IDs:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
# modules/profiles/interface/niri/meta.nix
|
||||||
|
{
|
||||||
|
includes = [
|
||||||
|
"applications.niri"
|
||||||
|
"applications.ghostty"
|
||||||
|
"applications.noctalia"
|
||||||
|
"applications.vicinae"
|
||||||
|
"applications.nautilus"
|
||||||
|
"services.xdg-portal"
|
||||||
|
];
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Never omit a prefix such as `applications.` merely because the including unit is
|
||||||
|
a profile. Fully qualified IDs make ownership explicit and allow moves, name
|
||||||
|
collisions, and missing dependencies to be detected. Do not enable another unit
|
||||||
|
by assigning to its enable option from a class fragment; declare the dependency
|
||||||
|
in `meta.includes`.
|
||||||
|
|
||||||
|
Application metadata should include only dependencies technically required for
|
||||||
|
the application to work. A profile owns the user's choice to adopt several
|
||||||
|
otherwise independent applications together. For example, niri may include the
|
||||||
|
Wayland foundation and xdg-desktop-portal as technical dependencies, while
|
||||||
|
`profiles.interface.niri` selects Ghostty, Vicinae, Noctalia, and Nautilus.
|
||||||
|
Ghostty must not depend on niri, and niri-specific keybindings remain owned by
|
||||||
|
the niri unit.
|
||||||
|
|
||||||
|
## Profiles
|
||||||
|
|
||||||
|
Profiles compose units by purpose or form factor; they do not replace clear
|
||||||
|
application, system, service, or hardware ownership. Suitable profile namespaces
|
||||||
|
include:
|
||||||
|
|
||||||
|
```text
|
||||||
|
modules/profiles/
|
||||||
|
├── base/
|
||||||
|
├── interface/
|
||||||
|
│ ├── niri/
|
||||||
|
│ ├── gnome/
|
||||||
|
│ ├── cli-minimal/
|
||||||
|
│ └── cli-interactive/
|
||||||
|
├── platform/
|
||||||
|
│ ├── laptop/
|
||||||
|
│ ├── thinkpad/
|
||||||
|
│ ├── desktop/
|
||||||
|
│ ├── vm/
|
||||||
|
│ └── wsl/
|
||||||
|
├── workload/
|
||||||
|
│ ├── development/
|
||||||
|
│ ├── personal/
|
||||||
|
│ ├── server/
|
||||||
|
│ └── remote/
|
||||||
|
└── security/
|
||||||
|
└── secure-boot/
|
||||||
|
```
|
||||||
|
|
||||||
|
The `desktop/` name above is a form-factor profile under `profiles/platform/`,
|
||||||
|
not a top-level module category.
|
||||||
|
|
||||||
|
A profile may consist only of `meta.includes`. Small settings that belong only
|
||||||
|
to the composition and have no useful independent identity may go directly in
|
||||||
|
the profile's `nixos.nix`, `darwin.nix`, or `home.nix`. Extract configuration to
|
||||||
|
an appropriate application, system, service, or hardware unit when any of these
|
||||||
|
conditions holds:
|
||||||
|
|
||||||
|
- It should be independently enableable.
|
||||||
|
- Multiple profiles reuse it.
|
||||||
|
- It owns separate configuration files.
|
||||||
|
- Its NixOS, nix-darwin, and Home Manager implementations differ.
|
||||||
|
- Other units depend on it.
|
||||||
|
- It involves a daemon, permissions, or user groups.
|
||||||
|
|
||||||
|
## Registry Responsibilities
|
||||||
|
|
||||||
|
Implement unit discovery with Nix standard functionality such as
|
||||||
|
`builtins.readDir`. Do not depend on an external indiscriminate auto-import
|
||||||
|
mechanism, and do not design the repository around `import-tree`. Registry logic
|
||||||
|
has these responsibilities:
|
||||||
|
|
||||||
|
1. Recursively visit directories below `modules/`.
|
||||||
|
2. Check only the five reserved filenames directly within each directory.
|
||||||
|
3. Register a directory as a unit when at least one reserved file exists there.
|
||||||
|
4. Derive the unit ID from the path relative to `modules/`.
|
||||||
|
5. Record only class fragments that exist.
|
||||||
|
6. Evaluate `meta.nix` as a descriptor only when it exists.
|
||||||
|
7. Exclude non-reserved files from discovery and implicit imports.
|
||||||
|
8. Generate every unit's `my.<unit path>.enable` option.
|
||||||
|
9. Enable included units from `meta.includes`.
|
||||||
|
10. Raise a clear evaluation error for a reference to a missing unit ID.
|
||||||
|
11. Apply only the fragments appropriate to the current host class.
|
||||||
|
12. Pass `home.nix` to Home Manager only for hosts that enable Home Manager.
|
||||||
|
|
||||||
|
A unit record may conceptually look like this; the implementation need not use
|
||||||
|
this exact representation:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
{
|
||||||
|
id = "applications.ghostty";
|
||||||
|
directory = ./applications/ghostty;
|
||||||
|
|
||||||
|
fragments = {
|
||||||
|
common = null;
|
||||||
|
nixos = null;
|
||||||
|
darwin = null;
|
||||||
|
home = ./applications/ghostty/home.nix;
|
||||||
|
};
|
||||||
|
|
||||||
|
meta = { };
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Keep the custom Registry limited to unit discovery, enable-option generation,
|
||||||
|
`includes`, and class dispatch. Do not reimplement general Nix imports or Nix
|
||||||
|
module evaluation. In particular, never infer a unit ID from metadata or
|
||||||
|
implicitly load a non-reserved file.
|
||||||
|
|
||||||
|
## Hosts and Class Dispatch
|
||||||
|
|
||||||
|
`hosts/` is outside Registry discovery. A host contains machine-specific facts,
|
||||||
|
differences, and unit selection, not reusable shared configuration. Appropriate
|
||||||
|
host-owned data includes:
|
||||||
|
|
||||||
|
- Generated `hardware-configuration.nix`.
|
||||||
|
- Disk UUIDs and disko target devices.
|
||||||
|
- Monitor identifiers, layout, and scale.
|
||||||
|
- MAC addresses and static IP addresses.
|
||||||
|
- Kernel parameters required by one machine only.
|
||||||
|
- `system.stateVersion`.
|
||||||
|
- Host-specific secret references.
|
||||||
|
- The profiles, applications, and other units enabled on that host.
|
||||||
|
|
||||||
|
A host registry may use a specification like this:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
# hosts/default.nix
|
||||||
|
{
|
||||||
|
x1g13 = {
|
||||||
|
system = "x86_64-linux";
|
||||||
|
user = "moons";
|
||||||
|
path = ./x1g13;
|
||||||
|
|
||||||
|
profiles = [
|
||||||
|
"base"
|
||||||
|
"platform.thinkpad"
|
||||||
|
"interface.niri"
|
||||||
|
"interface.gnome"
|
||||||
|
"workload.development"
|
||||||
|
"workload.personal"
|
||||||
|
"security.secure-boot"
|
||||||
|
];
|
||||||
|
|
||||||
|
applications = [
|
||||||
|
"codex-desktop"
|
||||||
|
];
|
||||||
|
|
||||||
|
units = [
|
||||||
|
"services.tailscale"
|
||||||
|
];
|
||||||
|
};
|
||||||
|
|
||||||
|
macbook = {
|
||||||
|
system = "aarch64-darwin";
|
||||||
|
user = "moons";
|
||||||
|
path = ./macbook;
|
||||||
|
|
||||||
|
profiles = [
|
||||||
|
"base"
|
||||||
|
"platform.laptop"
|
||||||
|
"workload.development"
|
||||||
|
"workload.personal"
|
||||||
|
];
|
||||||
|
|
||||||
|
applications = [
|
||||||
|
"ghostty"
|
||||||
|
];
|
||||||
|
};
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Treat entries in `profiles` and `applications` as IDs relative to their
|
||||||
|
respective category roots. Add the category prefixes during host construction:
|
||||||
|
|
||||||
|
```nix
|
||||||
|
selectedUnits =
|
||||||
|
[ "users.${spec.user}" ]
|
||||||
|
++ map (name: "profiles.${name}") spec.profiles
|
||||||
|
++ map (name: "applications.${name}") spec.applications
|
||||||
|
++ spec.units or [ ];
|
||||||
|
```
|
||||||
|
|
||||||
|
`units` is an escape hatch for fully qualified service, system, hardware, or
|
||||||
|
other unit IDs. Prefer profiles for the main composition; do not make hosts list
|
||||||
|
large numbers of low-level units directly.
|
||||||
|
|
||||||
|
Host modules use normal Nix module semantics and are not Registry-guarded
|
||||||
|
configuration fragments. For example:
|
||||||
|
|
||||||
|
```text
|
||||||
|
hosts/x1g13/
|
||||||
|
├── nixos.nix
|
||||||
|
├── home.nix
|
||||||
|
├── hardware-configuration.nix
|
||||||
|
└── disko.nix
|
||||||
|
```
|
||||||
|
|
||||||
|
`hosts/x1g13/nixos.nix` may explicitly load `hardware-configuration.nix` and
|
||||||
|
`disko.nix` with the normal top-level Nix module `imports`. Do not confuse these
|
||||||
|
host imports with the prohibition on top-level `imports` in unit configuration
|
||||||
|
fragments.
|
||||||
|
|
||||||
|
Derive the system class from the host's `system`:
|
||||||
|
|
||||||
|
- A Linux NixOS host receives `common.nix` and `nixos.nix`.
|
||||||
|
- A nix-darwin host receives `common.nix` and `darwin.nix`.
|
||||||
|
- A host with integrated Home Manager additionally receives `home.nix`.
|
||||||
|
|
||||||
|
Home Manager is additive, not a system class mutually exclusive with NixOS or
|
||||||
|
nix-darwin. The supported combinations are NixOS plus Home Manager and
|
||||||
|
nix-darwin plus Home Manager. If standalone Home Manager is supported later, add
|
||||||
|
an explicit host kind because `system` alone cannot distinguish it from NixOS.
|
||||||
|
|
||||||
|
Do not duplicate reusable settings in hosts, but do not force genuinely
|
||||||
|
machine-specific values into a common unit merely to remove a host-local line.
|
||||||
|
|
||||||
|
## Coding Style and Implementation Rules
|
||||||
|
|
||||||
|
Use two-space indentation in Nix files and let `nixfmt` decide layout. Prefer
|
||||||
|
small units, explicit imports, and descriptive kebab-case names, for example
|
||||||
|
`modules/services/media-server/nixos.nix`. Use camelCase for Nix attributes
|
||||||
|
unless an upstream option dictates otherwise. Shell snippets must pass `shfmt`
|
||||||
|
and `shellcheck`; YAML, TOML, and Markdown are formatted by the configured
|
||||||
|
treefmt tools.
|
||||||
|
|
||||||
|
When implementing or modifying modules:
|
||||||
|
|
||||||
|
- Do not create `features/` or a top-level `desktop/` module category.
|
||||||
|
- Do not add per-unit `mkEnableOption`, `cfg`, or `mkIf` boilerplate; the Registry
|
||||||
|
derives and guards enable options from paths.
|
||||||
|
- Put unit dependencies in `meta.includes`, not in direct assignments to another
|
||||||
|
unit's enable option from a class fragment.
|
||||||
|
- Do not assume any non-reserved file is discovered or loaded automatically.
|
||||||
|
- Do not require an `_` prefix for helper or private files.
|
||||||
|
- Do not create unused `common.nix`, `nixos.nix`, `darwin.nix`, `home.nix`, or
|
||||||
|
`meta.nix` files.
|
||||||
|
- Do not override a path-derived unit ID from `meta.nix`.
|
||||||
|
- Keep technical application dependencies separate from the applications a
|
||||||
|
personal environment chooses to combine in a profile.
|
||||||
|
- Do not rely on module-list ordering to override values. Use Nix module
|
||||||
|
priorities such as `lib.mkDefault`, `lib.mkForce`, `lib.mkBefore`, or
|
||||||
|
`lib.mkAfter` explicitly when required.
|
||||||
|
- Keep Registry responsibilities narrow; use normal Nix imports and module
|
||||||
|
evaluation for everything outside discovery, generated enables, includes, and
|
||||||
|
class dispatch.
|
||||||
|
|
||||||
## Build, Test, and Development Commands
|
## Build, Test, and Development Commands
|
||||||
|
|
||||||
- `nix develop .#dotnix` enters the main development shell and installs the repository's pre-commit hooks.
|
- `nix develop .#dotnix` enters the main development shell and installs the
|
||||||
- `nix develop .#android` provides Android platform tools such as `adb` and `fastboot`.
|
repository's pre-commit hooks.
|
||||||
|
- `nix develop .#android` provides Android platform tools such as `adb` and
|
||||||
|
`fastboot`.
|
||||||
- `nix fmt` formats all supported files through treefmt.
|
- `nix fmt` formats all supported files through treefmt.
|
||||||
- `nix flake check` evaluates flake outputs and runs configured checks.
|
- `nix flake check` evaluates flake outputs and runs configured checks.
|
||||||
- `pre-commit run --all-files` runs formatting, dead-code and static Nix checks, shell linting, and secret scanning.
|
- `pre-commit run --all-files` runs formatting, dead-code and static Nix checks,
|
||||||
- `nix flake update` refreshes pinned inputs in `flake.lock`; review lockfile changes before committing.
|
shell linting, and secret scanning.
|
||||||
|
- `nix flake update` refreshes pinned inputs in `flake.lock`; review lockfile
|
||||||
|
changes before committing.
|
||||||
|
|
||||||
If direnv is installed, `direnv allow` activates the `dotnix` shell from `.envrc` automatically.
|
If direnv is installed, `direnv allow` activates the `dotnix` shell from `.envrc`
|
||||||
|
automatically.
|
||||||
## Coding Style & Naming Conventions
|
|
||||||
|
|
||||||
Use two-space indentation in Nix files and let `nixfmt` decide layout. Prefer small modules with explicit imports and descriptive kebab-case filenames, for example `modules/services/media-server.nix`. Use camelCase for Nix attributes unless an upstream option dictates otherwise. Shell snippets must pass `shfmt` and `shellcheck`; YAML, TOML, and Markdown are formatted by the configured treefmt tools.
|
|
||||||
|
|
||||||
## Testing Guidelines
|
## Testing Guidelines
|
||||||
|
|
||||||
There is no separate unit-test suite. Before submitting changes, run `nix flake check` and `pre-commit run --all-files`. For system-specific changes, also build or evaluate the affected NixOS/Home Manager configuration without switching the live machine. Never commit generated secrets, `.age` plaintext, or local `.direnv/` state.
|
There is no separate unit-test suite. Before submitting changes, run
|
||||||
|
`nix flake check` and `pre-commit run --all-files`. For system-specific changes,
|
||||||
|
also build or evaluate the affected NixOS, nix-darwin, or Home Manager
|
||||||
|
configuration without switching the live machine. Never commit generated
|
||||||
|
secrets, `.age` plaintext, or local `.direnv/` state.
|
||||||
|
|
||||||
## Commit & Pull Request Guidelines
|
For Registry changes, test discovery of each supported fragment combination,
|
||||||
|
dependency closure through `meta.includes`, missing-unit errors, and class
|
||||||
|
dispatch. Verify that helper files are ignored until explicitly imported and
|
||||||
|
that directories without a directly contained reserved file remain namespaces.
|
||||||
|
|
||||||
Recent history favors short, lowercase, imperative subjects such as `fix` and `update action`; automated dependency commits use `chore(deps): ...`. Prefer a specific summary that states the affected area, such as `shells: add deployment tools`. Keep commits focused. Pull requests should explain the motivation, list affected hosts or profiles, report validation commands, and note any manual migration or secret-management steps. Include screenshots only for visible desktop or application configuration changes.
|
## Commit and Pull Request Guidelines
|
||||||
|
|
||||||
|
Recent history favors short, lowercase, imperative subjects such as `fix` and
|
||||||
|
`update action`; automated dependency commits use `chore(deps): ...`. Prefer a
|
||||||
|
specific summary that states the affected area, such as
|
||||||
|
`shells: add deployment tools`. Keep commits focused. Pull requests should
|
||||||
|
explain the motivation, list affected hosts or profiles, report validation
|
||||||
|
commands, and note any manual migration or secret-management steps. Include
|
||||||
|
screenshots only for visible desktop or application configuration changes.
|
||||||
|
|||||||
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
@@ -0,0 +1,89 @@
|
|||||||
|
# Bashtop theme with Nord palette (https://www.nordtheme.com)
|
||||||
|
# by Justin Zobel <[email protected]>
|
||||||
|
|
||||||
|
# Colors should be in 6 or 2 character hexadecimal or single spaced rgb decimal: "#RRGGBB", "#BW" or "0-255 0-255 0-255"
|
||||||
|
# example for white: "#ffffff", "#ff" or "255 255 255".
|
||||||
|
|
||||||
|
# All graphs and meters can be gradients
|
||||||
|
# For single color graphs leave "mid" and "end" variable empty.
|
||||||
|
# Use "start" and "end" variables for two color gradient
|
||||||
|
# Use "start", "mid" and "end" for three color gradient
|
||||||
|
|
||||||
|
# Main background, empty for terminal default, need to be empty if you want transparent background
|
||||||
|
theme[main_bg]="#282A36"
|
||||||
|
|
||||||
|
# Main text color
|
||||||
|
theme[main_fg]="#BD93F9"
|
||||||
|
|
||||||
|
# Title color for boxes
|
||||||
|
theme[title]="#f8f8f2"
|
||||||
|
|
||||||
|
# Highlight color for keyboard shortcuts
|
||||||
|
theme[hi_fg]="#ff79c6"
|
||||||
|
|
||||||
|
# Background color of selected item in processes box
|
||||||
|
theme[selected_bg]="#44475A"
|
||||||
|
|
||||||
|
# Foreground color of selected item in processes box
|
||||||
|
theme[selected_fg]="#ECEFF4"
|
||||||
|
|
||||||
|
# Color of inactive/disabled text
|
||||||
|
theme[inactive_fg]="#6272a4"
|
||||||
|
|
||||||
|
# Misc colors for processes box including mini cpu graphs, details memory graph and details status text
|
||||||
|
theme[proc_misc]="#BD93F9"
|
||||||
|
|
||||||
|
# Cpu box outline color
|
||||||
|
theme[cpu_box]="#ff79c6"
|
||||||
|
|
||||||
|
# Memory/disks box outline color
|
||||||
|
theme[mem_box]="#ff79c6"
|
||||||
|
|
||||||
|
# Net up/down box outline color
|
||||||
|
theme[net_box]="#ff79c6"
|
||||||
|
|
||||||
|
# Processes box outline color
|
||||||
|
theme[proc_box]="#ff79c6"
|
||||||
|
|
||||||
|
# Box divider line and small boxes line color
|
||||||
|
theme[div_line]="#ff79c6"
|
||||||
|
|
||||||
|
# Temperature graph colors
|
||||||
|
theme[temp_start]="#bd93f9"
|
||||||
|
theme[temp_mid]="#bd93f9"
|
||||||
|
theme[temp_end]="#bd93f9"
|
||||||
|
|
||||||
|
# CPU graph colors
|
||||||
|
theme[cpu_start]="#bd93f9"
|
||||||
|
theme[cpu_mid]="#bd93f9"
|
||||||
|
theme[cpu_end]="#bd93f9"
|
||||||
|
|
||||||
|
# Mem/Disk free meter
|
||||||
|
theme[free_start]="#bd93f9"
|
||||||
|
theme[free_mid]="#bd93f9"
|
||||||
|
theme[free_end]="#bd93f9"
|
||||||
|
|
||||||
|
# Mem/Disk cached meter
|
||||||
|
theme[cached_start]="#bd93f9"
|
||||||
|
theme[cached_mid]="#bd93f9"
|
||||||
|
theme[cached_end]="#bd93f9"
|
||||||
|
|
||||||
|
# Mem/Disk available meter
|
||||||
|
theme[available_start]="#bd93f9"
|
||||||
|
theme[available_mid]="#bd93f9"
|
||||||
|
theme[available_end]="#bd93f9"
|
||||||
|
|
||||||
|
# Mem/Disk used meter
|
||||||
|
theme[used_start]="#bd93f9"
|
||||||
|
theme[used_mid]="#bd93f9"
|
||||||
|
theme[used_end]="#bd93f9"
|
||||||
|
|
||||||
|
# Download graph colors
|
||||||
|
theme[download_start]="#bd93f9"
|
||||||
|
theme[download_mid]="#bd93f9"
|
||||||
|
theme[download_end]="#bd93f9"
|
||||||
|
|
||||||
|
# Upload graph colors
|
||||||
|
theme[upload_start]="#bd93f9"
|
||||||
|
theme[upload_mid]="#bd93f9"
|
||||||
|
theme[upload_end]="#bd93f9"
|
||||||
@@ -0,0 +1,8 @@
|
|||||||
|
{
|
||||||
|
programs.btop = {
|
||||||
|
enable = true;
|
||||||
|
|
||||||
|
settings.color_theme = "dracula";
|
||||||
|
themes.dracula = builtins.readFile ./dracula.theme;
|
||||||
|
};
|
||||||
|
}
|
||||||
Reference in New Issue
Block a user