nixos-config/README.adoc

= foo-dogsquared's NixOS config
:toc:
:devos_link: https://github.com/divnix/digga/tree/580fc57ffaaf9cf3a582372235759dccfe44ac92/examples/devos
:canonical_flake_url: github:foo-dogsquared/nixos-config
:canonical_flake_url_tarball_master: https://github.com/foo-dogsquared/nixos-config/archive/master.tar.gz
:canonical_flake_url_tarball_specific: https://github.com/foo-dogsquared/nixos-config/archive/35c27749c55077727529f412dade862e4deb2ae8.tar.gz

This is my NixOS config as a link:https://www.tweag.io/blog/2020-05-25-flakes/[Nix flake].

I finally have some time trying to grok flakes and redo my NixOS config from scratch after leaving it for some time (because I have work and have to quickly set things up without me trying to debug how NixOS works).
Here is the result.




== Getting started

[CAUTION]
====
Despite being a NixOS system, it isn't entirely reproducible to the point of installing this config will work out-of-the-box.
It has some things needed in the first place to work like my external backup setup where it needs my SSH private keys to work in the first place.
Nonetheless, the parts is it isn't reproducible is only about 10% of this config.
Everything else is fine and dandy.

Oh right...
Don't expect everything is working in each commit but I'm doing my best to make them build successfully in each, yeah?

Also, this configuration is expected to use under non-restricted evaluation mode.
====

Hey there, fellow traveler!
You've fell into the rabbit hole we call Nix where it leads to other rabbit holes such as functional package management, reproducibility, declarative systems, and immutable operating systems.

This is one of the many tickets to that rabbit hole, allow me to be your guide in this mark:[painful] wonderful declarative journey.
Hope to see you on the other side!


=== Installation

Since this uses Nix flakes, you should have Nix v2.8 and above installed.

If you're going to install one of my NixOS configs, be sure to download the unstable versions from link:https://releases.nixos.org/?prefix=nixos/unstable/[their release page].
As an additional option, you can also use link:https://github.com/foo-dogsquared/nixos-config/releases/tag/latest[my personalized NixOS installers] which is primarily intended for me configs.

This primarily uses Nix flakes so you can have a preview of what's available in my config.

[source, shell, subs=attributes]
----
nix flake show {canonical_flake_url}
----

It should export my NixOS configurations of my different hosts (of only one so far excluding VMs and VPSs ;p) among other things.
To install it, run the `nixos-install --flake {canonical_flake_url}#ni`.
(Please see the respective appropriate host README for more information.)


[#channels-support]
=== Channels support

While this primarily uses flakes as its main form of distribution, this project does keep some use cases for traditional channels.
It's not guaranteed to be good as using it <<using-my-config-with-flakes>> but it's an option.

The entry point is found at link:./default.nix[`./default.nix`].
However, you have to keep some limitations and guidelines in mind.

* It exports an attribute based from the link:https://github.com/nix-community/NUR/[NUR template].
+
--
Several exports includes...

* My custom library at `lib`.
* Custom NixOS modules at `modules`.
* Custom home-manager modules at `hmModules`.
* An overlay of my custom packages at `overlays.foo-dogsquared-pkgs`.
* My packages as the rest of the top-level attributes from the attrset.
--

* Keep in mind it doesn't export the NixOS hosts and home-manager user configurations.
It would be pointless as it is duplicating effort plus I __really like managing my NixOS config more with the flakes way__ compared to setting up channels.
It has a lot of advantages such as the ease of provisioning and updating your setups along with its dependencies, enforcing certain values in a certain attribute that can be seen in the revised Nix CLI, and nicer interface overall.
While possible with channels, this is just better experience overall and I have no interest in maintaining setups in both ways.


[#whats-in-my-flake]
=== What's in my flake?

You can see the full details with `nix flake show`.
As a helpful summary, here's what my flake should contain sorting from the most interesting and helpful outputs to the most boring and unnecessary.

* `packages` contains link:./pkgs[my custom packages] and some of usual images of several hosts which is nice for easily fetching custom images.

* `overlays` contains the overlay for extending nixpkgs with my packages.
If you want to use my packages alongside the nixpkgs attribute then this is what you're looking for.

* `homeModules` are where my link:./modules/home-manager[custom home-manager modules] to be exported.
footnote:[This is more useful than my NixOS modules.]

* `nixosModules` are composed from NixOS modules defined in link:./modules/nixos[`./modules/nixos`].
It can be used as additional modules for your own NixOS config in case you want to use mine for whatever reason.
There are some niceties in there.
+
--
A few examples include:

* A NixOS module for Pop launcher plugins and scripts.
* Several service modules for archiving with link:https://github.com/yt-dlp/yt-dlp[yt-dlp], link:https://github.com/mikf/gallery-dl/[gallery-dl], and link:https://archivebox.io/[ArchiveBox].
* My themes which contain full desktop environments which is nice for quickly initializing a NixOS configuration.
--

* `devShells` from link:./shells/[my custom environments].
Similar to `homeConfigurations`, you can easily use it outside of NixOS.

* `homeConfigurations` contains my various link:https://github.com/nix-community/home-manager[home-manager] configurations from link:./users/home-manager/[`./users/home-manager/`].
The neat thing about it is you can easily install it in a non-NixOS Linux distro.

* `deploy` are nodes to be deployed by link:https://github.com/serokell/deploy-rs[deploy-rs].
It's nice and currently not all of the nodes are publicly committed which is less useful but it'll be someday.

* `nixosConfigurations` which is where you can install my various NixOS configurations directly (e.g., `nixos-install --flake {canonical_flake_url}#HOST`).
This mainly uses the link:./hosts/[hosts configuration].

* `templates` which contains my templates.
Though, these are just templates mostly for my own purposes so it is not as useful as the other outputs.

* `hydraJobs` contains link:https://github.com/NixOS/hydra[Hydra] build jobs where it is primarily used for my test Hydra instance.

* `lib` is defined from link:./lib/[my custom library].
It mainly assumes it is to be included in nixpkgs standard library (i.e., `import ./lib { lib = inputs.nixpkgs.lib; }`).
It's another unnecessary export but it's there.

* `formatter` is the preferred formatter to be used for my Nix files.
Nothing special here.

* `checks` contains checks for several outputs and are mainly for internal purposes.
There's no use for anyone else, really. :(


=== What should not be here?

Despite being a NixOS configuration, this is not meant to be fully reproducible by anyone.
There are still some things that would need to be privately held as indicated by the following list.

- Associated private keys: GPG, SSH, age, you name it.
They are used with a secret management tool (see <<secrets-management>> for more information) to encrypt the more sensitive parts of the system such as credentials and environment files.

- Disposable hosts configurations.
They will typically just make a messier mess than the current situation.

Though the unreproducible part is only like 10% of the whole configuration, it can be successfully deployed by anyone.
Keep in mind, it comes with a few restrictions due to the lack of the appropriate credentials.

- Certain tasks will not start.
Most of the project tasks found in this repo requires the associated private key with the task.
An example would be the link:./modules/nixos/tasks/backup-archive[Borg backup task] where it needs several files and credentials locked from the secrets management tool.

- Certain components will be missing.
Most notably, the associated SSH key for the hosts.
You won't be able to connect to the host if you don't have the private key.

- Not to mention not all modules listed committed here are up-to-date.
Though this only applies to non-critical services like the link:./modules/nixos/tasks/multimedia-archive[multimedia archiving service].


=== The remote repo

For a complete overkill, we use a CI to further the configuration abomination.
It uses GitHub workflows to enable things such as...

* Automatically building link:./pkgs[my custom packages] and sending them to my binary cache to easily distribute it for others.
* Building my personalized NixOS installers and link:https://github.com/foo-dogsquared/nixos-config/releases[making a release out of it].
* Testing the flake outputs (in progress lel).


=== Project structure

Last and foremost, we have the project directory —  the environment you'll be living in for the next year, tinkering your Nix configs.
.
It is required to be familiar with the workspace, after all.
My configuration takes a lot of cues from link:{devos_link}[devos] (which is unfortunately is a lot to take if you're just beginning to grok Nix as a whole).

My NixOS config should look like the following:

[source, tree]
----
nixos-config
├── hosts/
├── lib/
├── modules/
├── pkgs/
├── scripts/
├── secrets/
├── shells/
├── templates/
├── users/
├── default.nix
├── flake.lock
├── flake.nix
├── images.toml
└── README.adoc
----

One of the more notable files here when first start looking is the link:./images.toml[`./images.toml`] file where it contains a description of the images.
For more details, see <<declarative-host-management>>.

Most of the said folders are related to a flake output attribute, see <<whats-in-my-flake>> for more details.

* link:./hosts/[`./hosts/`] contain machine-specific configuration.
This usually configures like the hardware setup, timezone, and users.
Host configurations are also exported in the flakes in `outputs.nixosConfigurations`.

* link:./modules/[`./modules/`] contain my custom modules including NixOS and home-manager modules.
For more information, see the link:./modules/README.adoc[related documentation].

* link:./pkgs/[`./pkgs/`] contains my custom packages.
It is exported in the flakes at `outputs.packages` compiled through various systems.

* link:./scripts/[`./scripts/`] contains various scripts for various purposes.
Should be self-explanatory.

* link:./secrets/[`./secrets/`] contains my cluster-wide secrets managed with link:https://github.com/mozilla/sops[sops] and link:https://github.com/Mic92/sops-nix[sops-nix].
Take note, each component (e.g., hosts, modules, users) could have their own specific secrets.

* link:./shells/[`./shells/`] contains my development shells for interacting with the usual type of projects.
Setting this up can bring benefits outside of NixOS (unless you're interacting with projects with any OpenGL-related stuff).
footnote:[Since packages brought from Nix shells can only work with the store, a container might be better at some situations.]

* link:./templates/[`./templates/`] contains my custom templates handy for quickly initializing for various types of projects.

* link:./users/[`./users/`] contains my link:https://github.com/nix-community/home-manager[home-manager] configurations.
It is exported in the flakes at `outputs.homeConfigurations`.
For more information, see the link:./users/README.adoc[related documentation].


[#declarative-host-management]
=== Declarative host management

This project uses a custom setup for declarative host management.
Specifically, it is done with a simple file at link:./images.toml[`./images.toml`] where it expects a table of the hosts' metadata.
Each host in the table represents one of the hosts at link:./hosts/[`./hosts/`].

A host metadata has a certain schema which the following example is a complete version of it.
The data is then used for certain functions in the flake definition file (i.e., `flake.nix`).

[#lst:images-metadata-example]
[source, toml]
----
[plover]
system = "x86_64-linux"
format = "iso"
hostname = "ploverrific"
domain = "foodogsquared.one"
nixpkgs-channel = "nixos-unstable-small"

[plover.deploy]
hostname = "plover.foodogsquared.one"
fast-connection = true
auto-rollback = true
magic-rollback = true
remote-build = true
----

For a complete reference, here are the expected attributes.

- `system` contains the platform of the host system.
This is mainly used to indicate the platform used for the nixpkgs repository.

- `format` is the image output format for the host.
It expects an accepted value from link:https://github.com/nix-community/nixos-generators[nixos-generators] project.

- `hostname` is the canonical hostname for the host.
If unset, the hostname is the name of the table key.
In the <<lst:images-metadata-example, previous example>>, if `plover.hostname` is unset, the value would be `plover` instead of `ploverrific`.

- `domain` is the domain used for networking configuration.
It is set for `networking.domain` in NixOS configuration.

- `nixpkgs-channel` is the nixpkgs channel to be used for the host.
The value could be any one of the nixpkgs flake inputs imported into this flake.
By default, it uses `nixpkgs` flake input which points to the `nixos-unstable` channel.

- `deploy` is a table containing arguments from link:https://github.com/serokell/deploy-rs[deploy-rs].
Only a few arguments are accepted (i.e., `hostname`, `fast-connection`, `remote-build`, `magic-rollback`, and `auto-rollback`).

Take note, only certain hosts can be considered as a NixOS configuration (e.g., `nixosConfigurations`).
Specifically, those images with a format of `iso` and those without (since they fall back to `iso` anyways).
Those NixOS configuration are then included as part of the deploy nodes for deploy-rs.
Otherwise, most images are intended to be built.
footnote:[Though, one could create a custom activation and deployment script with deploy-rs.]


[#declarative-user-management]
=== Declarative user management

Similarly to <<declarative-host-management>>, this project also provides a way to declare home-manager users.

Similar to `images.toml`, it expects a table of users with each representing one of the users from link:./users/home-manager/[`./users/home-manager/`].
These are then included as part of `homeConfigurations` for easier installation with the standalone home-manager tool.
Of which they are then included as part of deploy nodes for deploy-rs (also for easier deployment).

Here's an example user with complete schema.

[source, toml]
----
[foo-dogsquared]
system = "x86_64-linux"
home-manager-channel = "home-manager-23.05"
home-directory = "/home/foo-dogsquared"
username = "foodogsquared"
----

- `system` contains the platform of the home-manager user.
This is mainly used to indicate the platform used for the nixpkgs repository.

- `home-manager-channel` contains the home-manager channel to be used.
The value should be one of the home-manager channel that is imported into this flake.
By default, it sets the home-manager channel at `home-manager` which is pointed at the unstable channel.

- `home-directory` is the associated home directory of the home-manager.
It is set for `config.home.directory` at the home-manager configuration.
By default, it will be set at `/home/$USERNAME`.

- `username` is the username of the home-manager user to be used for `config.home.username` at the home-manager configuration.
If unset, it will use the table key.
In the above example, the unset value would be `foo-dogsquared`.


[#secrets-management]
=== Secrets management

This repo uses link:https://github.com/mozilla/sops[sops] as the main secret management tool.
For integrating this into NixOS, I use link:https://github.com/Mic92/sops-nix[sops-nix].

To get started using sops, I recommend to take a look at `.sops.yaml` file which secrets belong to whom.
Then edit a secrets with `sops PATH_TO_SECRET`.
Take note, you need to respective keys to edit the secret in the first place.
If you edit `./secrets/backup-archive.yaml` for example, it needs one of the keys (either my age and GPG key or the age key from host `ni`).




== Using parts of my configuration

Hey there, stranger.
Wanted to try parts of my configuration but don't want to copy it outright since you're feeling lazy or what-have-you?
I made my configuration to be easy to use and integrate into your system.

Here's how...


[#using-my-config-with-flakes]
=== With flakes

This is the recommended method since I primarily use flakes for this project.
Not to mention that with flakes, this is easier than ever to make use parts of my configuration.

To start, you can simply add my flake to your list of flake inputs.

[source, nix, subs=attributes]
----
inputs.foo-dogsquared-nixos-config.url = "{canonical_flake_url}";
----

Then, you could use parts of the config as exported from my flake which you can refer back to <<whats-in-my-flake>>.

For example, you could make use of my packages by adding them as an overlay which is recommended if you're going to use my NixOS modules anyways.
Here's one way to put as part of your NixOS configuration...

[source, nix]
----
{
  nixpkgs.overlays = [
    inputs.foo-dogsquared-nixos-config.overlays.default
  ];
}
----

...or import them as part of nixpkgs.

[source, nix]
----
import nixpkgs {
  system = "x86_64-linux";
  overlays = [
    inputs.foo-dogsquared-nixos-config.overlays.default
  ];
}
----

If you're going to use my stuff, why don't take a gander and try my non-personal parts of the configuration such as my link:./modules/nixos/[NixOS modules] and link:./modules/home-manager[home-manager modules]?
In that case, you can simply plop them into your list of imports for your NixOS configuration like so.

[source, nix]
----
{
  imports = [
    inputs.foo-dogsquared-nixos-config.nixosModules.programs
    inputs.foo-dogsquared-nixos-config.nixosModules.services
    inputs.foo-dogsquared-nixos-config.nixosModules.workflows
  ];

  # Use my GNOME desktop configuration for some reason.
  workflows.workflows.a-happy-gnome.enable = true;
}
----


[#using-my-config-with-channels]
=== With channels

The traditional way of managing stuff with link:https://nixos.org/manual/nix/stable/package-management/channels.html[channels].
Though, I have made some efforts to make it easy to use without flakes, I cannot guarantee it's good compared to using it with flakes.

WARNING: You cannot install my NixOS configurations at all with channels so there's another reason why (whether is valid or not is completely up to you).

To start, as root, you have to add my project into the channels list...

[source, shell, subs=attributes]
----
nix-channel --add "{canonical_flake_url_tarball_master}" foo-dogsquared-nixos-config
nix-channel --update
----

...then import my config as part of your configuration.

[source, nix]
----
import <foo-dogsquared-nixos-config> { inherit pkgs; }
----

You can see link:./default.nix[`./default.nix`] to see more details but there are general guidelines to the attributes that is contained in this file which is outlined in <<channels-support>> section.

Here's an example snippet in a NixOS config making use of my configuration without flakes:

[source, nix]
----
let
  foo-dogsquared-nixos-config = import <foo-dogsquared-nixos-config> { inherit pkgs; };
in {
  imports = [
    foo-dogsquared-nixos-config.modules.programs
    foo-dogsquared-nixos-config.modules.services
    foo-dogsquared-nixos-config.modules.workflows
  ];

  # Still using my GNOME desktop configuration for some reason.
  workflows.workflows.a-happy-gnome.enable = true;
}
----


=== With manual fetching

If you really don't want to manage stuff with channels or with flakes for some reason, I suppose you can just use something like link:https://github.com/nmattia/niv/[niv].
You could also pin my config similarly to link:https://nix.dev/tutorials/towards-reproducibility-pinning-nixpkgs[how you can pin nixpkgs] then use it as if you manage it as described from <<using-my-config-with-channels>>.

Here's a snippet of using it as part of a NixOS configuration.

[source, nix, subs=attributes]
----
let
  foo-dogsquared-nixos-config = import (fetchTarball "{canonical_flake_url_tarball_specific}") { inherit pkgs; };
in {
  imports = [
    foo-dogsquared-nixos-config.modules.programs
    foo-dogsquared-nixos-config.modules.services
    foo-dogsquared-nixos-config.modules.workflows
  ];

  # Still using my GNOME desktop configuration for some reason.
  workflows.workflows.a-happy-gnome.enable = true;
}
----




== TODO

In order of priority:

* [x] Create custom modules.
* [x] Create a themes system similar to link:https://github.com/hlissner/dotfiles[this NixOS config].
* [x] Create a good workflow for creating ISOs.
* [x] Create development shells.
* [x] Manage secrets with agenix.
* [ ] Create a good workflow for tests.
* [x] Automate backups with NixOS config.
* [x] Create custom packages and export it to flakes. (Maybe consider making it to upstream)
* [x] Create cluser-wide configs.
* [x] Create host-wide configs.
* [x] Create user-specific configs with home-manager.
* [x] ~Steal~ Get some ideas from link:{devos_link}[this overengineered template].
* [x] Make use of other established utilities such as link:https://github.com/divnix/digga/[digga], link:https://github.com/gytis-ivaskevicius/flake-utils-plus[flake-utils-plus], and link:https://github.com/nix-community/home-manager[home-manager] once I'm familiar to create my own Nix programs.


=== Out of scope:

* Set most program configurations with Nix.
This is especially applicable to programs I always use such as my text editor configs.

** The reason: managing them can be chaotic when applied with Nix.
The potential for it is pretty nice especially when seen with similar implementations such as Guix home environment.
However, I don't want to rebuild it every time I change it.

** Plus, most of my applications are now installed using link:https://flatpak.org/[Flatpak] anyways.
It is a tad easier to manage configurations installed this way (e.g., just copy `~/.var` between your systems or make backups with it).

* Migration of my link:https://github.com/foo-dogsquared/dotfiles[dotfiles].
I still use it on other non-NixOS systems.

* To be a configuration framework.
This is my personal configuration which means experimentation will always be here.
Sudden changes can happen at any point.




== Frequently asked questions (FAQ)

More like "Most anticipated questions (MAQ)" since almost no one asked me about this yet. :)
However, it doesn't roll off the tongue.

[qanda]
I'm new to Nix and NixOS, where should I start?::
Oh no, you've seen the multiple configurations from other systems, didn't you?
+
--
I hope you're ready for some time understanding because the learning curve is steeper than the link:https://en.wikipedia.org/wiki/Troll_Wall[Troll Wall].
I've written link:https://foo-dogsquared.github.io/blog/posts/moving-into-nixos/[a blog post regarding my experience with Nix] with a bunch of links for getting started.
Fortunately footnote:[Or unfortunately from a different perspective.], it is mostly the same experience now that I've revisited it.
(That said, Nix Pills is getting better!)

For a more practical start, I recommend to look into several configurations to see the general gist of configuration with Nix.
Here's a few I personally dug into:

* {devos_link}
* https://github.com/hlissner/dotfiles
* https://github.com/thiagokokada/nix-configs
--

Should I use NixOS?::
I feel like link:https://github.com/hlissner/dotfiles/blob/5ea10e188354d096566a364016fbd28ec38dbe07/README.md#frequently-asked-questions[this answer is enough] but I'll give my take on it regardless.
+
--
If you are looking forward to debugging your configuration which consists of finding multiple sources from the manuals from the website, reading the source code from the appropriate point in link:https://github.com/NixOS/nixpkgs/[nixpkgs], and repeatedly testing your NixOS configurations with each change then this is for you.

Entering the Nix ecosystem at the beginning requires high level of engagement to learn the ropes even if your only intention is to create a basic reproducible operating system ala-Ansible.

* You'll encounter vague and unique errors as the likes of NixOS is a unique world (the infamous infinite recursion, anyone?).
* You'll appreciate technical writers as the documentation department is lacking.
* You'll read outdated unofficial guides, resources, and the source code as you dive deeper into Nix.
* You'll get used to the unfortunate UX that is the toolings around Nix (even the revised Nix CLI has its problems).

There's nothing better with NixOS than the (un)official NixOS experience™.

Once you passed the initial curve and the difficulties that come with Nix, the benefits are immense.

* Using Nix beyond package management.
** As a universal build system due to its ability to install and integrate multiple versions of the same program without problems and decent support for different projects use cases (i.e., programming languages, build systems).
** As a link:https://virtualenv.pypa.io/[virtualenv]-like environment useful for managing development environments.
** As a way to manage clusters and infrastructure (i.e., link:https://nixos.org/[NixOS] for your installations, link:https://github.com/NixOS/nixops[nixops] for deployment, link:https://github.com/NixOS/hydra[Hydra] for continuous integration).

* You can make use of Nix's large ecosystem of packages and tools from nixpkgs and beyond.

* It is easier to distribute and verify your builds as Nix also has toolings available for those purposes. footnote:[Though, other packaging formats also has those but for Nix, reproducibility is one of the focus.]

If you intend to use NixOS, I recommend to start small and install Nix on a non-NixOS distro and use it as a way to create reproducible development environment, be familiar to its build process (I recommend reading link:https://nixos.org/guides/nix-pills[Nix Pills] to get started), get intimate with systemd, and then test NixOS in a virtual machine.
--

Any requirements for this setup?::
You only need Nix 2.6 installed with the experimental features for Nix command and flakes enabled (i.e., `experimental-features = nix-command flakes`).

Hey! I have an error something like `/nix/${HASH}-nmd/` from my installation. Why it doesn't work?::
This error seems to be related to home-manager.
See this link:https://github.com/nix-community/home-manager/issues/2074[issue] for more details.
Basically, you have to add `--impure` flag when running `nixos-install`.

What is my experience on Nix flakes?::
link:https://youtu.be/iWJKZK_1l88[I LIKE IT!]
There are still some hiccups like the strict tie-in to Git which leads to strange experience like having to add untracked files just to be recognized.
However, this feature is still in the works so no surprise there.
+
--
With that said, it is workable to be a daily part of the NixOS experience especially with the benefits of Nix flakes.

* More user-friendly compared to Nix channels.
* Just one reference file to know what is being exported from a project.
* Unification with commonly-agreed schemas.

This feature somewhat helped me understand more about the Nix language, oddly.
I guess those lightbulb moments can come from random places.
--

Is this based from link:{devos_link}[devos]?::
Yes but I've created this from scratch.
One of my goals when creating this config is to use as little dependency as much as possible and to understand more what's going under the hood with Nix.
At the time I've rewritten this configuration, I have little idea about Nix as a language and I find devos to be overwhelming so I doubled down to create from scratch.
+
However, I can say that my configuration is moving in a similar direction to devos (which is intended to be modified anyways) as I explore more of Nix.
In fact, I've based much of my config from it and may even be ended up as one.
It is nice that such a project exists serving as a reference for bigger configurations.

What's up with some error regarding something in restricted mode?::
If you found some error regarding something in restricted mode, you can run the installation with `--impure` flag (i.e., `nixos-install --impure --flake {canonical_flake_url}#ni`).




== Inspirations and acknowledgment

I ~stole~ got several parts of this configuration from the following projects:

* link:{devos_link}[devos, an overengineered configuration framework.]
I'm slowly grokking Nix and its ecosystem so I didn't use this outright.
Though, this is where my config is heading to be and instead slowly making parts of my config based from this template.

* link:https://github.com/divnix/digga/[digga, an flake utility library for your overengineered config.]
I also stole parts of it for my custom library.
I may have to use this at some point.

* link:https://github.com/hlissner/dotfiles/[hlissner's dotfiles, the original inspiration for this functional abomination of a configuration.]
Very nice.


== Copyright

This project is licensed under MIT license.
I just chose it to make it easier to upstream parts of this project to nixpkgs and to make it easier to copy it without much problems (just don't forget to add attribution as indicated from the license).
Please see link:./LICENSE[`./LICENSE`] for the full text.