Merge pull request #235 from divnix/release-0.9.0

Prepare 0.9.0 release

.github/workflows/mdbook_docs.yml

@@ -16,12 +16,12 @@ jobs:
         with:
           mdbook-version: 'latest'
 
-      - run: mdbook build
+      - run: mdbook build doc
 
       - name: Deploy
         uses: peaceiris/actions-gh-pages@v3
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           publish_branch: gh-pages
-          publish_dir: ./book
+          publish_dir: ./doc/book
           cname: devos.divnix.com

.gitignore

@@ -2,4 +2,4 @@ result
 up
 hosts/up-*
 .direnv
-book
+doc/index.html

README.md

@@ -55,10 +55,10 @@ There are two branches from which to choose: [core][core] and
 several ready-made profiles for discretionary use.
 
 Every package and NixOS profile declared in community is uploaded to
-[cachix](./cachix), so everything provided is available without building
-anything. This is especially useful for the packages that are
-[overridden](./overrides) from master, as without the cache, rebuilds are
-quite frequent.
+[cachix](./integrations/cachix.md), so everything provided is available
+without building anything. This is especially useful for the packages that are
+[overridden](./concepts/overrides.md) from master, as without the cache,
+rebuilds are quite frequent.
 
 ## Inspiration & Art
 - [hlissner/dotfiles][dotfiles]

default.nix

@@ -1,8 +1,31 @@
 let
   inherit (default.inputs.nixos) lib;
 
-  default = (import ./compat).defaultNix;
+  default = (import "${./lib}/compat").defaultNix;
+
+  ciSystems = [
+    "aarch64-linux"
+    "i686-linux"
+    "x86_64-linux"
+  ];
+
+  filterSystems = lib.filterAttrs
+    (system: _: lib.elem system ciSystems);
+
+  recurseIntoAttrsRecursive = lib.mapAttrs (_: v:
+    if lib.isAttrs v
+    then recurseIntoAttrsRecursive (lib.recurseIntoAttrs v)
+    else v
+  );
+
+  systemOutputs = lib.filterAttrs
+    (name: set: lib.isAttrs set
+      && lib.any
+      (system: set ? ${system} && name != "legacyPackages")
+      ciSystems
+    )
+    default.outputs;
+
+  ciDrvs = lib.mapAttrs (_: system: filterSystems system) systemOutputs;
 in
-builtins.mapAttrs (_: v: lib.recurseIntoAttrs v) default.packages // {
-  shell = import ./shell.nix;
-}
+(recurseIntoAttrsRecursive ciDrvs) // { shell = import ./shell.nix; }

doc/SUMMARY.md

@@ -0,0 +1,34 @@
+# Summary
+
+- [Introduction](../README.md)
+- [Quick Start](./start/index.md)
+  - [ISO](./start/iso.md)
+  - [Bootstrapping](./start/bootstrapping.md)
+  - [From NixOS](./start/from-nixos.md)
+- [Key Concepts](./concepts/index.md)
+  - [Extern](./concepts/extern.md)
+  - [Hosts](./concepts/hosts.md)
+  - [Overrides](./concepts/overrides.md)
+  - [Profiles](./concepts/profiles.md)
+  - [Suites](./concepts/suites.md)
+  - [Users](./concepts/users.md)
+- [Outputs](./outputs/index.md)
+  - [Modules](./outputs/modules.md)
+  - [Overlays](./outputs/overlays.md)
+  - [Packages](./outputs/pkgs.md)
+- [Concerns]()
+  - [Lib](./lib.md)
+  - [Secrets](./secrets.md)
+  - [Tests](./tests.md)
+- [Helper Script – `flk`](./flk/index.md)
+  - [up](./flk/up.md)
+  - [update](./flk/update.md)
+  - [get](./flk/get.md)
+  - [iso](./flk/iso.md)
+  - [install](./flk/install.md)
+  - [home](./flk/home.md)
+- [Integrations](./integrations/index.md)
+  - [Cachix](./integrations/cachix.md)
+  - [Deploy RS](./integrations/deploy.md)
+  - [Hercules CI](./integrations/hercules.md)
+- [Contributing](./CONTRIBUTING.md)

hosts/README.md → doc/concepts/hosts.md

@@ -17,16 +17,16 @@ matching the current systems hostname if one is not specified explicitly.
 
 It is recommended that the host modules only contain configuration information
 specific to a particular piece of hardware. Anything reusable across machines
-is best saved for [profile modules](../profiles).
+is best saved for [profile modules](./profiles.md).
 
-This is a good place to import sets of profiles, called [suites](../suites),
+This is a good place to import sets of profiles, called [suites](./suites.md),
 that you intend to use on your machine.
 
 Additionally, this is the perfect place to import anything you might need from
 the [nixos-hardware][nixos-hardware] repository.
 
 > ##### _Note:_
-> Set `nixpkgs.system` to the architecture of this host, default is "x86_64-linux". 
+> Set `nixpkgs.system` to the architecture of this host, default is "x86_64-linux".
 > Keep in mind that not all packages are available for all architectures.
 
 ## Example

doc/concepts/index.md

@@ -0,0 +1,4 @@
+# Key Concepts
+
+There are few idioms unique to DevOS. This section is dedicated to helping you
+understand them.

overrides/README.md → doc/concepts/overrides.md

@@ -1,13 +1,14 @@
 # Overrides
-By default, the NixOS systems are based on the latest release. While it is
-trivial to change this to nixos-unstable or any other branch of nixpkgs by
+By default, the NixOS systems are based on unstable. While it is trivial to
+change this to a stable release, or any other branch of nixpkgs by
 changing the flake url, sometimes all we want is a single package from another
 branch.
 
 This is what the overrides are for. By default, they are pulled directly from
 nixpkgs/master, but you can change the `override` flake input url to
 nixos-unstable, or even a specific sha revision.
 
+They are defined in the `extern/overrides.nix` file.
 
 ## Example
 

profiles/README.md → doc/concepts/profiles.md

@@ -12,17 +12,17 @@ is maintained to help get up to speed on their usage.
 For the sake of consistency, a profile should always be defined in a
 ___default.nix___ containing a [nixos module config][config].
 A profile's directory is used for quick modularization of
-[interelated bits](./#subprofiles).
+[interelated bits](./profiles.md#subprofiles).
 
 > ##### _Notes:_
-> * For _declaring_ module options, there's the [modules](../modules) directory.
+> * For _declaring_ module options, there's the [modules](../outputs/modules.md) directory.
 > * This directory takes inspiration from
 >   [upstream](https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/profiles)
 >   .
 > * Sticking to a simple [spec][spec] has refreshing advantages.
->   [hercules-ci](../doc/integrations/hercules.md) expects all profiles to be
+>   [hercules-ci](../integrations/hercules.md) expects all profiles to be
 >   defined in a ___default.nix___, allowing them to be built automatically when
->   added. Congruently, [suites](../suites) expect ___default.nix___ to avoid
+>   added. Congruently, [suites](suites.md) expect ___default.nix___ to avoid
 >   having to manage their paths manually.
 
 ## Subprofiles
@@ -56,7 +56,7 @@ profiles/develop/zsh/default.nix:
 Profiles are the most important concept in DevOS. They allow us to keep our
 Nix expressions self contained and modular. This way we can maximize reuse
 across hosts while minimizing boilerplate. Remember, anything machine
-specific belongs in your [host](../hosts) files instead.
+specific belongs in your [host](hosts.md) files instead.
 
 [definition]: https://nixos.org/manual/nixos/stable/index.html#sec-option-definitions
 [declaration]: https://nixos.org/manual/nixos/stable/index.html#sec-option-declarations

suites/README.md → doc/concepts/suites.md

@@ -6,6 +6,8 @@ profiles. For good examples, check out the suites defined in the community
 In the future, we will use suites as a mechanism for deploying various machine
 types which don't depend on hardware, such as vm's and containers.
 
+They are defined in `profiles/suites.nix`.
+
 ## Definition
 ```nix
 rec {

users/README.md → doc/concepts/users.md

@@ -1,6 +1,6 @@
 # Users
 
-Users are a special case of [profiles](../profiles) that define system
+Users are a special case of [profiles](profiles.md) that define system
 users and [home-manager][home-manager] configurations. For your convenience,
 home manager is wired in by default so all you have to worry about is declaring
 your users. For a fully fleshed out example, check out the developers personal
@@ -24,14 +24,14 @@ your users. For a fully fleshed out example, check out the developers personal
 
 ## Home Manager
 Home Manager support follows the same principles as regular nixos configurations.
-All modules defined in [user modules](./modules/module-list.nix) will be imported to 
-Home Manager. All profiles are availabe in [suites](../suites/default.nix) as userProfiles.
+All modules defined in [user modules][modules-list] will be imported to
+Home Manager. All profiles are availabe in [suites][suites] as userProfiles.
 The `userSuites` output will be available in your Home Manager Configuration as
 the special argument, `suites`.
 
 ## External Usage
 You can easily use the defined home-manager configurations outside of NixOS
-using the `homeConfigurations` flake output. The [flk](../doc/flk) helper 
+using the `homeConfigurations` flake output. The [flk](../flk/index.md) helper
 script makes this even easier.
 
 This is great for keeping your environment consistent across Unix systems,
@@ -56,3 +56,5 @@ nix build "github:divnix/devos#homeConfigurations.nixos@NixOS.home.activationPac
 ```
 
 [home-manager]: https://nix-community.github.io/home-manager
+[suites]: https://github.com/divnix/devos/tree/core/suites/default.nix
+[modules-list]: https://github.com/divnix/devos/tree/core/modules/module-list.nix

doc/flk/home.md

@@ -4,5 +4,5 @@ NixOS, providing an awesome mechanism for keeping your environments
 synchronized, even when using other systems.
 
 ## Usage
-The [users](../../users/index.md#external-usage) page contains a good usage
+The [users](../concepts/users.md#external-usage) page contains a good usage
 example.

doc/flk/update.md

@@ -11,8 +11,8 @@ contains a flake.nix, with an optional arguement to update only a specific
 input in the subflake.
 
 For example, you can update any
-[package sources](../../pkgs#automatic-source-updates) you may have declared
-in _pkgs/flake.nix_:
+[package sources](../outputs/pkgs.md#automatic-source-updates) you may have
+declared in _pkgs/flake.nix_:
 ```sh
 flk update pkgs
 ```

doc/integrations/cachix.md

@@ -0,0 +1,17 @@
+# Cachix
+The system will automatically pull a cachix.nix at the root if one exists.
+This is usually created automatically by a `sudo cachix use`. If your more
+inclined to keep the root clean, you can drop any generated files in the
+`cachix` directory into the `profiles/cachix` directory without further
+modification.
+
+For example, to add your own cache, assuming the template lives in /etc/nixos,
+by simply running `sudo cachix use yourcache`. Then, optionally, move
+`cachix/yourcache.nix` to `profiles/cachix/yourcache.nix`
+
+These caches are only added to the system after a `nixos-rebuild switch`, so it
+is recommended to call `cachix use nrdxp` before the initial deployment, as it
+will save a lot of build time.
+
+In the future, users will be able to skip this step once the ability to define
+the nix.conf within the flake is fully fleshed out upstream.

doc/integrations/deploy.md

@@ -4,7 +4,7 @@ chosen for devos after the author experienced some frustrations with the
 stateful nature of nixops' db. It was also designed from scratch to support
 flake based deployments, and so is an excellent tool for the job.
 
-By default, all the [hosts](../../hosts) are also available as deploy-rs nodes,
+By default, all the [hosts](../concepts/hosts.md) are also available as deploy-rs nodes,
 configured with the hostname set to `networking.hostName`; overridable via
 the command line.
 

doc/integrations/hercules.md

@@ -15,7 +15,7 @@ binary cache (and of course you do), be sure _not_ to skip the
 [binary-caches.json][cache].
 
 ## Ready to Use
-The repo is already set up with the proper _nix/ci.nix_ file, building all
+The repo is already set up with the proper _default.nix_ file, building all
 declared packages, checks, profiles and shells. So you can see if something
 breaks, and never build the same package twice!
 

doc/outputs/index.md

@@ -0,0 +1,3 @@
+# Layout
+Each of the following sections is a directory whose contents are output to the
+outside world via the flake's outputs. Check each chapter for details.

modules/README.md → doc/outputs/modules.md

@@ -4,13 +4,13 @@ The modules directory is a replica of nixpkg's NixOS [modules][nixpkgs-modules]
 nixpkgs proper once your module is sufficiently stable.
 
 All modules linked in _module-list.nix_ are automatically exported via
-`nixosModules.<file-basename>`, and imported into all [hosts](../hosts).
+`nixosModules.<file-basename>`, and imported into all [hosts](../concepts/hosts.md).
 
 
 > ##### _Note:_
 > This is reserved for declaring brand new module options. If you just want to
 > declare a coherent configuration of already existing and related NixOS options
-> , use [profiles](../profiles) instead.
+> , use [profiles](../concepts/profiles.md) instead.
 
 ## Semantics
 In case you've never written a module for nixpkgs before, here is a brief

overlays/README.md → doc/outputs/overlays.md

@@ -3,7 +3,7 @@ Writing overlays is a common occurence when using a NixOS system. Therefore,
 we want to keep the process as simple and straightforward as possible.
 
 Any _.nix_ files declared in this directory will be assumed to be a valid
-overlay, and will be automatically imported into all [hosts](../hosts), and
+overlay, and will be automatically imported into all [hosts](../concepts/hosts.md), and
 exported via `overlays.<file-basename>` _as well as_
 `packages.<system>.<pkgName>` (for valid systems), so all you have to do is
 write it.