NixOS daily driver
Go to file
2020-01-03 19:07:42 -07:00
hosts flake.nix: name flake inputs 2020-01-03 18:27:52 -07:00
lib utils: small cleanup 2019-12-21 19:02:22 -07:00
local core: don't import file systems 2020-01-01 19:21:15 -07:00
modules modules#qbittorrent: add openFirewall option 2020-01-01 16:24:36 -07:00
pkgs Initialize template branch 2020-01-03 17:47:17 -07:00
profiles Initialize template branch 2020-01-03 17:47:17 -07:00
.envrc Initialize template branch 2020-01-03 17:47:17 -07:00
.gitattributes setup configurations API 2019-12-05 01:58:40 -07:00
.gitignore setup configurations API 2019-12-05 01:58:40 -07:00
configuration.nix legacy: ensure config exists 2020-01-01 17:16:38 -07:00
COPYING init 2019-12-02 22:18:30 -07:00
flake.lock graphical#ffmpeg: build with svt-av1 support 2019-12-30 18:42:36 -07:00
flake.nix flake.nix: name flake inputs 2020-01-03 18:27:52 -07:00
README.md README.md: link to nrdxp branch 2020-01-03 19:07:42 -07:00
shell.nix users: create on entering nix-shell 2020-01-03 18:06:01 -07:00

Introduction

This project is under construction as a rewrite of my legacy NixOS configuration, using the experimental flakes mechanism. Its aim is to provide a generic template repository, to neatly separate concerns and allow one to get up and running with NixOS faster. Flakes are still an experimental feature, but once they finally get merged, even more will become possible, including nixops support.

Flake Talk

Usage

Enter a nix-shell either manually or automatically using direnv. This will set up the exerimental nix features that need to be available to use flakes.

Start a new branch based on the template branch:

git checkout -b <new_branch> template

You may want to use a generated hardware config for your machine:

nixos-generate-config --show-hardware-config > ./hosts/<new_host>.nix

A basic rebuild command is included in the shell to replace nixos-rebuild for now.

Usage: rebuild [host] {switch|boot|test}

#example using above generated config
rebuild <new_host> switch

You can specify one of the host configurations from the hosts directory. If omitted, it will default to your systems current hostname.

And now you should be ready to start writing your nix configuration or import some of the already existing profiles. Review contributing below on how to structure your expressions. And be sure to update the locale.nix for your region.

You can always check out my personal branch nrdxp, to get an idea of how to structure your work.

Additional Capabilities

In addtion:

rebuild iso

Will make a minimal and bootable iso image of the niximg configuration. You can customize the image by editing this file.

You can also install the packages declared in pkgs without needing to install NixOS. For example:

# from top-level
nix profile install ".#packages.x86_64-linux.purs"

A similar mechanism exists to import the modules and overlays declared in the flake to allow for seemless sharing between configurations.

Contributing

The purpose of this repository is to provide a standardized template structure for NixOS machine expressions, thus enabling simpler sharing and resue of nix expressions.

Say your friend and you are using this repository, each with your own unique nix epxpressions. By simply importing your friends flake from flake.nix as an input, you can have access to all of the packages, modules, overlays, and even entire system configurations your friend has defined!

Hosts

Distributions for particular machines should be stored in the hosts directory. Every file in this directory will be added automatically to the available NixOS configurations available in the nixosConfigurations flake output. See the default.nix for implementation details.

Profiles

More abstract configurations that can be reused by multiple machines should go in the profiles directory. We make a distinction between a module and profile, in that a profile is simly a regular NixOS module, without any new option declarations.

Every profile should have a default.nix to easily import it. You can also stick things in the profile's subdirectory which are not automatically imported, but are meant to be manually imported from a host (useful for less common, or specialized configurations).

Importantly, every subdirectory in a profile should be independantly importable. For example, a zsh directory lives under profiles/develop. It's written in a generic way to allow in to be imported without the entire develop if one so wished. This provides a wonderful level of granularity.

In addition, profiles can depend on other profiles. For example, The graphical profile depends on develop simply by importing it in its default.nix.

Users

User declaration belongs in the users directory. Everything related to your user should be declared here. For convenience, home-manager is available automatically for home directory setup.

Secrets

Anything you wish to keep encrypted goes in the secrets directory, which is created on first entering a nix-shell.

Be sure to run git crypt init, before committing anything to this directory. Be sure to check out git-crypts documentation if your not familiar. The filter is already set up to encrypt everything in this folder by default.

To keep profiles resuable across configurations, secrets should only be imported from the users directory.

Modules and Packages

All modules and pkgs are available for every configuration automatically. Simply add a *.nix file to one of these directories declaring your module or package, and update the corresponding default.nix to point to it. Now you can use your new module or install your new package as usual.

Doing this will also add them to the flake's nixosModules or overlays outputs to import them easily into an external NixOS configuration as well.

Pull Requests

While much of your work in this template may be idiosyncratic in nature. Anything that might be generally useful to the broader NixOS community can be synced to the template branch to provide a host of useful NixOS configurations available "out of the box". If you wish to contribute such an expression please follow the following guidelines.

Be sure to format your code with nixpkgs-fmt before opening a pull-request. The commit message follows the same semantics as nixpkgs. You can use a # symbol to specify abiguities. For example, develop#zsh: <rest of commit message> would tell me that your updating the zsh configuration living under the develop profile.

License

This software is licensed under the MIT License.

Note: MIT license does not apply to the packages built by this configuration, merely to the files in this repository (the Nix expressions, build scripts, NixOS modules, etc.). It also might not apply to patches included here, which may be derivative works of the packages to which they apply. The aforementioned artifacts are all covered by the licenses of the respective packages.