this repo has no description
4
fork

Configure Feed

Select the types of activity you want to include in your feed.

Merge pull request #235 from divnix/release-0.9.0

Prepare 0.9.0 release

authored by

Timothy DeHerrera and committed by
GitHub
9eeddb8d 658cd2bb

+188 -165
-23
.github/workflows/community_sync.yml
··· 1 - name: Sync Community Branch 2 - 3 - on: 4 - workflow_run: 5 - workflows: 6 - - "CI - Changelog" 7 - - "Release" 8 - types: 9 - - completed 10 - branches: 11 - - core 12 - 13 - jobs: 14 - merge-core-to-community: 15 - name: Merge core -> community 16 - runs-on: ubuntu-latest 17 - 18 - steps: 19 - - uses: tukasz/direct-merge-action@master 20 - with: 21 - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 22 - source-branch: core 23 - target-branch: community
+2 -2
.github/workflows/mdbook_docs.yml
··· 16 16 with: 17 17 mdbook-version: 'latest' 18 18 19 - - run: mdbook build 19 + - run: mdbook build doc 20 20 21 21 - name: Deploy 22 22 uses: peaceiris/actions-gh-pages@v3 23 23 with: 24 24 github_token: ${{ secrets.GITHUB_TOKEN }} 25 25 publish_branch: gh-pages 26 - publish_dir: ./book 26 + publish_dir: ./doc/book 27 27 cname: devos.divnix.com
+1 -1
.gitignore
··· 2 2 up 3 3 hosts/up-* 4 4 .direnv 5 - book 5 + doc/index.html
+4 -4
README.md
··· 55 55 several ready-made profiles for discretionary use. 56 56 57 57 Every package and NixOS profile declared in community is uploaded to 58 - [cachix](./cachix), so everything provided is available without building 59 - anything. This is especially useful for the packages that are 60 - [overridden](./overrides) from master, as without the cache, rebuilds are 61 - quite frequent. 58 + [cachix](./integrations/cachix.md), so everything provided is available 59 + without building anything. This is especially useful for the packages that are 60 + [overridden](./concepts/overrides.md) from master, as without the cache, 61 + rebuilds are quite frequent. 62 62 63 63 ## Inspiration & Art 64 64 - [hlissner/dotfiles][dotfiles]
-32
SUMMARY.md
··· 1 - # Summary 2 - 3 - - [Introduction](./README.md) 4 - - [Quick Start](./doc/start/index.md) 5 - - [ISO](./doc/start/iso.md) 6 - - [Bootstrapping](./doc/start/bootstrapping.md) 7 - - [From NixOS](./doc/start/from-nixos.md) 8 - - [Layout](./doc/layout.md) 9 - - [Cachix](./cachix/README.md) 10 - - [Extern](./extern/README.md) 11 - - [Hosts](./hosts/README.md) 12 - - [Lib](./lib/README.md) 13 - - [Modules](./modules/README.md) 14 - - [Overlays](./overlays/README.md) 15 - - [Overrides](./overrides/README.md) 16 - - [Packages](./pkgs/README.md) 17 - - [Profiles](./profiles/README.md) 18 - - [Secrets](./secrets/README.md) 19 - - [Suites](./suites/README.md) 20 - - [Tests](./tests/README.md) 21 - - [Users](./users/README.md) 22 - - [flk](./doc/flk/index.md) 23 - - [up](./doc/flk/up.md) 24 - - [update](./doc/flk/update.md) 25 - - [get](./doc/flk/get.md) 26 - - [iso](./doc/flk/iso.md) 27 - - [install](./doc/flk/install.md) 28 - - [home](./doc/flk/home.md) 29 - - [Integrations](doc/integrations/index.md) 30 - - [Deploy RS](./doc/integrations/deploy.md) 31 - - [Hercules CI](./doc/integrations/hercules.md) 32 - - [Contributing](./doc/README.md)
book.toml doc/book.toml
+2 -3
cachix.nix profiles/cachix/default.nix
··· 1 - # WARN: this file will get overwritten by $ cachix use <name> 2 1 { pkgs, lib, ... }: 3 2 let 4 - folder = ./cachix; 3 + folder = ./.; 5 4 toImport = name: value: folder + ("/" + name); 6 - filterCaches = key: value: value == "regular" && lib.hasSuffix ".nix" key; 5 + filterCaches = key: value: value == "regular" && lib.hasSuffix ".nix" key && key != "default.nix"; 7 6 imports = lib.mapAttrsToList toImport (lib.filterAttrs filterCaches (builtins.readDir folder)); 8 7 in 9 8 {
-12
cachix/README.md
··· 1 - # Cachix 2 - The cachix directory simple captures the output of `sudo cachix use` for the 3 - developers personal cache, as well as the nix-community cache. You can easily 4 - add your own cache, assuming the template lives in /etc/nixos, by simply 5 - running `sudo cachix use yourcache`. 6 - 7 - These caches are only added to the system after a `nixos-rebuild switch`, so it 8 - is recommended to call `cachix use nrdxp` before the initial deployment, as it 9 - will save a lot of build time. 10 - 11 - In the future, users will be able to skip this step once the ability to define 12 - the nix.conf within the flake is fully fleshed out upstream.
cachix/nix-community.nix profiles/cachix/nix-community.nix
cachix/nrdxp.nix profiles/cachix/nrdxp.nix
+2 -2
compat/default.nix lib/compat/default.nix
··· 1 1 let 2 2 inherit (lock.nodes.flake-compat.locked) rev narHash; 3 3 4 - lock = builtins.fromJSON (builtins.readFile ../flake.lock); 4 + lock = builtins.fromJSON (builtins.readFile "${../..}/flake.lock"); 5 5 flake = (import 6 6 ( 7 7 fetchTarball { ··· 10 10 } 11 11 ) 12 12 { 13 - src = ../.; 13 + src = ../../.; 14 14 }); 15 15 in 16 16 flake
compat/nixos/default.nix lib/compat/nixos/default.nix
+27 -4
default.nix
··· 1 1 let 2 2 inherit (default.inputs.nixos) lib; 3 3 4 - default = (import ./compat).defaultNix; 4 + default = (import "${./lib}/compat").defaultNix; 5 + 6 + ciSystems = [ 7 + "aarch64-linux" 8 + "i686-linux" 9 + "x86_64-linux" 10 + ]; 11 + 12 + filterSystems = lib.filterAttrs 13 + (system: _: lib.elem system ciSystems); 14 + 15 + recurseIntoAttrsRecursive = lib.mapAttrs (_: v: 16 + if lib.isAttrs v 17 + then recurseIntoAttrsRecursive (lib.recurseIntoAttrs v) 18 + else v 19 + ); 20 + 21 + systemOutputs = lib.filterAttrs 22 + (name: set: lib.isAttrs set 23 + && lib.any 24 + (system: set ? ${system} && name != "legacyPackages") 25 + ciSystems 26 + ) 27 + default.outputs; 28 + 29 + ciDrvs = lib.mapAttrs (_: system: filterSystems system) systemOutputs; 5 30 in 6 - builtins.mapAttrs (_: v: lib.recurseIntoAttrs v) default.packages // { 7 - shell = import ./shell.nix; 8 - } 31 + (recurseIntoAttrsRecursive ciDrvs) // { shell = import ./shell.nix; }
doc/README.md doc/CONTRIBUTING.md
+34
doc/SUMMARY.md
··· 1 + # Summary 2 + 3 + - [Introduction](../README.md) 4 + - [Quick Start](./start/index.md) 5 + - [ISO](./start/iso.md) 6 + - [Bootstrapping](./start/bootstrapping.md) 7 + - [From NixOS](./start/from-nixos.md) 8 + - [Key Concepts](./concepts/index.md) 9 + - [Extern](./concepts/extern.md) 10 + - [Hosts](./concepts/hosts.md) 11 + - [Overrides](./concepts/overrides.md) 12 + - [Profiles](./concepts/profiles.md) 13 + - [Suites](./concepts/suites.md) 14 + - [Users](./concepts/users.md) 15 + - [Outputs](./outputs/index.md) 16 + - [Modules](./outputs/modules.md) 17 + - [Overlays](./outputs/overlays.md) 18 + - [Packages](./outputs/pkgs.md) 19 + - [Concerns]() 20 + - [Lib](./lib.md) 21 + - [Secrets](./secrets.md) 22 + - [Tests](./tests.md) 23 + - [Helper Script – `flk`](./flk/index.md) 24 + - [up](./flk/up.md) 25 + - [update](./flk/update.md) 26 + - [get](./flk/get.md) 27 + - [iso](./flk/iso.md) 28 + - [install](./flk/install.md) 29 + - [home](./flk/home.md) 30 + - [Integrations](./integrations/index.md) 31 + - [Cachix](./integrations/cachix.md) 32 + - [Deploy RS](./integrations/deploy.md) 33 + - [Hercules CI](./integrations/hercules.md) 34 + - [Contributing](./CONTRIBUTING.md)
+4
doc/concepts/index.md
··· 1 + # Key Concepts 2 + 3 + There are few idioms unique to DevOS. This section is dedicated to helping you 4 + understand them.
+1 -1
doc/flk/home.md
··· 4 4 synchronized, even when using other systems. 5 5 6 6 ## Usage 7 - The [users](../../users/index.md#external-usage) page contains a good usage 7 + The [users](../concepts/users.md#external-usage) page contains a good usage 8 8 example.
+2 -2
doc/flk/update.md
··· 11 11 input in the subflake. 12 12 13 13 For example, you can update any 14 - [package sources](../../pkgs#automatic-source-updates) you may have declared 15 - in _pkgs/flake.nix_: 14 + [package sources](../outputs/pkgs.md#automatic-source-updates) you may have 15 + declared in _pkgs/flake.nix_: 16 16 ```sh 17 17 flk update pkgs 18 18 ```
+17
doc/integrations/cachix.md
··· 1 + # Cachix 2 + The system will automatically pull a cachix.nix at the root if one exists. 3 + This is usually created automatically by a `sudo cachix use`. If your more 4 + inclined to keep the root clean, you can drop any generated files in the 5 + `cachix` directory into the `profiles/cachix` directory without further 6 + modification. 7 + 8 + For example, to add your own cache, assuming the template lives in /etc/nixos, 9 + by simply running `sudo cachix use yourcache`. Then, optionally, move 10 + `cachix/yourcache.nix` to `profiles/cachix/yourcache.nix` 11 + 12 + These caches are only added to the system after a `nixos-rebuild switch`, so it 13 + is recommended to call `cachix use nrdxp` before the initial deployment, as it 14 + will save a lot of build time. 15 + 16 + In the future, users will be able to skip this step once the ability to define 17 + the nix.conf within the flake is fully fleshed out upstream.
+1 -1
doc/integrations/deploy.md
··· 4 4 stateful nature of nixops' db. It was also designed from scratch to support 5 5 flake based deployments, and so is an excellent tool for the job. 6 6 7 - By default, all the [hosts](../../hosts) are also available as deploy-rs nodes, 7 + By default, all the [hosts](../concepts/hosts.md) are also available as deploy-rs nodes, 8 8 configured with the hostname set to `networking.hostName`; overridable via 9 9 the command line. 10 10
+1 -1
doc/integrations/hercules.md
··· 15 15 [binary-caches.json][cache]. 16 16 17 17 ## Ready to Use 18 - The repo is already set up with the proper _nix/ci.nix_ file, building all 18 + The repo is already set up with the proper _default.nix_ file, building all 19 19 declared packages, checks, profiles and shells. So you can see if something 20 20 breaks, and never build the same package twice! 21 21
-4
doc/layout.md
··· 1 - # Layout 2 - Each of the following sections is a directory in the root of the project 3 - serving a singular purpose. Select a chapter to read more about its purpose 4 - and usage.
+3
doc/outputs/index.md
··· 1 + # Layout 2 + Each of the following sections is a directory whose contents are output to the 3 + outside world via the flake's outputs. Check each chapter for details.
+10 -10
doc/start/bootstrapping.md
··· 1 1 # Bootstrapping 2 2 3 - This will help you boostrap a bare host with the help of the 4 - [bespoke iso](./iso) live installer. 3 + This will help you boostrap a bare host with the help of the 4 + [bespoke iso](./iso.md) live installer. 5 5 6 - _Note: nothing prevents you from remotely executing the boostrapping 6 + _Note: nothing prevents you from remotely executing the boostrapping 7 7 process. See below._ 8 8 9 9 Once your target host has booted into the live iso, you need to partion ··· 14 14 Then properly mount the formatted partitions at `/mnt`, so that you can 15 15 install your system to those new partitions. 16 16 17 - Mount `nixos` partition to `/mnt` and &mdash; for UEFI &mdash; `boot` 17 + Mount `nixos` partition to `/mnt` and &mdash; for UEFI &mdash; `boot` 18 18 partition to `/mnt/boot`: 19 19 20 20 ```console ··· 25 25 26 26 ## Install 27 27 28 - Install using the `flk` wrapper baked into the iso off of a copy of devos 28 + Install using the `flk` wrapper baked into the iso off of a copy of devos 29 29 from the time the iso was built: 30 30 31 31 ```console ··· 41 41 ### Remote access to the live installer 42 42 43 43 The iso live installer comes preconfigured with a network configuration 44 - which announces it's hostname via [MulticastDNS][mDNS] as `hostname.local`, 44 + which announces it's hostname via [MulticastDNS][mDNS] as `hostname.local`, 45 45 that is `NixOS.local` in the [iso example](./iso). 46 46 47 47 In the rare case that [MulticastDNS][mDNS] is not availabe or turned off ··· 50 50 `n=14 i=9 x=24; 47 = n+i+x`). 51 51 52 52 Provided that you have added your public key to the authorized keys of the 53 - `root` user _(hint: [`deploy-rs`](../integrations/deploy) needs passwordless 53 + `root` user _(hint: [`deploy-rs`](../integrations/deploy.md) needs passwordless 54 54 sudo access)_: 55 55 56 56 ```nix ··· 62 62 } 63 63 ``` 64 64 65 - You can then ssh into the live installer through one of the 65 + You can then ssh into the live installer through one of the 66 66 following options: 67 67 68 68 ```console ··· 73 73 74 74 _Note: the [static link-local IPv6 address][staticLLA] and [MulticastDNS][mDNS] is only 75 75 configured on the live installer. If you wish to enable [MulticastDNS][mDNS] 76 - for your environment, you ought to configure that in a regular [profile](../../profiles)._ 76 + for your environment, you ought to configure that in a regular [profile](../concepts/profiles.md)._ 77 77 78 78 ### EUI-64 LLA & Host Identity 79 79 ··· 88 88 ip -6 neigh show # also shows fe80::47 89 89 ``` 90 90 91 - ***This LLA is stable for the host, unless you need to swap that particular network card.*** 91 + ***This LLA is stable for the host, unless you need to swap that particular network card.*** 92 92 Under this reservation, though, you may use this EUI-64 to wire up a specific 93 93 (cryptographic) host identity. 94 94
+2 -2
doc/start/from-nixos.md
··· 15 15 set to the filename of your hosts file, so `hosts/my-host.nix` will have the 16 16 hostname `my-host`. 17 17 18 - Now might be a good time to read the docs on [suites](../../suites) and 19 - [profiles](../../profiles) and add or create any that you need. 18 + Now might be a good time to read the docs on [suites](../concepts/suites.md) and 19 + [profiles](../concepts/profiles.md) and add or create any that you need. 20 20 21 21 > ##### _Note:_ 22 22 > While the `up` sub-command is provided as a convenience to quickly set up and
+1 -1
doc/start/index.md
··· 22 22 nix-shell that provides all the dependencies, including the unstable nix 23 23 version required. 24 24 25 - In addition, the [binary cache](../../cachix) is added for faster deployment. 25 + In addition, the [binary cache](../integrations/cachix.md) is added for faster deployment. 26 26 27 27 > ##### _Notes:_ 28 28 > - You can change `core` to [`community`](../../index.md#community-profiles)
+36
doc/tests.md
··· 1 + # Testing 2 + 3 + Testing is always an important aspect of any software development project, and 4 + NixOS offers some incredibly powerful tools to write tests for your 5 + configuration, and, optionally, run them in 6 + [CI](./integrations/hercules.md). 7 + 8 + ## Lib Tests 9 + You can easily write tests for your own library functions in the 10 + ___tests/lib.nix___ file and they will be run on every `nix flake check` or 11 + during a CI run. 12 + 13 + ## Unit Tests 14 + Unit tests are can be created from regular derivations, and they can do 15 + almost anything you can imagine. By convention, it is best to test your 16 + packages during their [check phase][check]. All packages and their tests will 17 + be built during CI. 18 + 19 + ## Integration Tests 20 + You can write integration tests for one or more NixOS VMs that can, 21 + optionally, be networked together, and yes, it's as awesome as it sounds! 22 + 23 + Be sure to use the `mkTest` function, in the [___tests/default.nix___][default] 24 + which wraps the official [testing-python][testing-python] function to ensure 25 + that the system is setup exactly as it is for a bare DevOS system. There are 26 + already great resources for learning how to use these tests effectively, 27 + including the official [docs][test-doc], a fantastic [blog post][test-blog], 28 + and the examples in [nixpkgs][nixos-tests]. 29 + 30 + [test-doc]: https://nixos.org/manual/nixos/stable/index.html#sec-nixos-tests 31 + [test-blog]: https://www.haskellforall.com/2020/11/how-to-use-nixos-for-lightweight.html 32 + [default]: https://github.com/divnix/devos/tree/core/tests/default.nix 33 + [run-test]: https://github.com/NixOS/nixpkgs/blob/6571462647d7316aff8b8597ecdf5922547bf365/lib/debug.nix#L154-L166 34 + [nixos-tests]: https://github.com/NixOS/nixpkgs/tree/master/nixos/tests 35 + [testing-python]: https://github.com/NixOS/nixpkgs/tree/master/nixos/lib/testing-python.nix 36 + [check]: https://nixos.org/manual/nixpkgs/stable/#ssec-check-phase
extern/README.md doc/concepts/extern.md
+2 -2
flake.nix
··· 37 37 inherit self; 38 38 hosts = ./hosts; 39 39 packages = import ./pkgs; 40 - suites = import ./suites; 40 + suites = import ./profiles/suites.nix; 41 41 extern = import ./extern; 42 - overrides = import ./overrides; 42 + overrides = import ./extern/overrides.nix; 43 43 overlays = ./overlays; 44 44 profiles = ./profiles; 45 45 userProfiles = ./users/profiles;
+3 -3
hosts/README.md doc/concepts/hosts.md
··· 17 17 18 18 It is recommended that the host modules only contain configuration information 19 19 specific to a particular piece of hardware. Anything reusable across machines 20 - is best saved for [profile modules](../profiles). 20 + is best saved for [profile modules](./profiles.md). 21 21 22 - This is a good place to import sets of profiles, called [suites](../suites), 22 + This is a good place to import sets of profiles, called [suites](./suites.md), 23 23 that you intend to use on your machine. 24 24 25 25 Additionally, this is the perfect place to import anything you might need from 26 26 the [nixos-hardware][nixos-hardware] repository. 27 27 28 28 > ##### _Note:_ 29 - > Set `nixpkgs.system` to the architecture of this host, default is "x86_64-linux". 29 + > Set `nixpkgs.system` to the architecture of this host, default is "x86_64-linux". 30 30 > Keep in mind that not all packages are available for all architectures. 31 31 32 32 ## Example
lib/README.md doc/lib.md
+1 -1
lib/devos/default.nix
··· 7 7 config = { allowUnfree = true; }; 8 8 }; 9 9 10 - profileMap = map (profile: profile.default); 10 + profileMap = list: map (profile: profile.default) (lib.flatten list); 11 11 12 12 mkNodes = dev.callLibs ./mkNodes.nix; 13 13
+6 -2
lib/devos/mkHosts.nix
··· 37 37 38 38 nix.nixPath = [ 39 39 "nixpkgs=${nixos}" 40 - "nixos-config=${self}/compat/nixos" 40 + "nixos-config=${self}/lib/compat/nixos" 41 41 "home-manager=${inputs.home}" 42 42 ]; 43 43 ··· 63 63 # Everything in `./modules/list.nix`. 64 64 flakeModules = { imports = builtins.attrValues self.nixosModules ++ extern.modules; }; 65 65 66 - cachix = ../../cachix.nix; 66 + cachix = let rootCachix = ../../cachix.nix; in 67 + if builtins.pathExists rootCachix 68 + then rootCachix 69 + else { } 70 + ; 67 71 }; 68 72 69 73 specialArgs = extern.specialArgs // { suites = suites.system; };
+2 -2
modules/README.md doc/outputs/modules.md
··· 4 4 nixpkgs proper once your module is sufficiently stable. 5 5 6 6 All modules linked in _module-list.nix_ are automatically exported via 7 - `nixosModules.<file-basename>`, and imported into all [hosts](../hosts). 7 + `nixosModules.<file-basename>`, and imported into all [hosts](../concepts/hosts.md). 8 8 9 9 10 10 > ##### _Note:_ 11 11 > This is reserved for declaring brand new module options. If you just want to 12 12 > declare a coherent configuration of already existing and related NixOS options 13 - > , use [profiles](../profiles) instead. 13 + > , use [profiles](../concepts/profiles.md) instead. 14 14 15 15 ## Semantics 16 16 In case you've never written a module for nixpkgs before, here is a brief
-31
nix/ci.nix
··· 1 - let 2 - inherit (default.inputs.nixos) lib; 3 - 4 - default = (import "${../.}/compat").defaultNix; 5 - 6 - ciSystems = [ 7 - "aarch64-linux" 8 - "i686-linux" 9 - "x86_64-linux" 10 - ]; 11 - 12 - filterSystems = lib.filterAttrs 13 - (system: _: lib.elem system ciSystems); 14 - 15 - recurseIntoAttrsRecursive = lib.mapAttrs (_: v: 16 - if lib.isAttrs v 17 - then recurseIntoAttrsRecursive (lib.recurseIntoAttrs v) 18 - else v 19 - ); 20 - 21 - systemOutputs = lib.filterAttrs 22 - (name: set: lib.isAttrs set 23 - && lib.any 24 - (system: set ? ${system} && name != "legacyPackages") 25 - ciSystems 26 - ) 27 - default.outputs; 28 - 29 - ciDrvs = lib.mapAttrs (_: system: filterSystems system) systemOutputs; 30 - in 31 - recurseIntoAttrsRecursive ciDrvs
+1 -1
overlays/README.md doc/outputs/overlays.md
··· 3 3 we want to keep the process as simple and straightforward as possible. 4 4 5 5 Any _.nix_ files declared in this directory will be assumed to be a valid 6 - overlay, and will be automatically imported into all [hosts](../hosts), and 6 + overlay, and will be automatically imported into all [hosts](../concepts/hosts.md), and 7 7 exported via `overlays.<file-basename>` _as well as_ 8 8 `packages.<system>.<pkgName>` (for valid systems), so all you have to do is 9 9 write it.
+3 -2
overrides/README.md doc/concepts/overrides.md
··· 1 1 # Overrides 2 - By default, the NixOS systems are based on the latest release. While it is 3 - trivial to change this to nixos-unstable or any other branch of nixpkgs by 2 + By default, the NixOS systems are based on unstable. While it is trivial to 3 + change this to a stable release, or any other branch of nixpkgs by 4 4 changing the flake url, sometimes all we want is a single package from another 5 5 branch. 6 6 ··· 8 8 nixpkgs/master, but you can change the `override` flake input url to 9 9 nixos-unstable, or even a specific sha revision. 10 10 11 + They are defined in the `extern/overrides.nix` file. 11 12 12 13 ## Example 13 14
overrides/default.nix extern/overrides.nix
+4 -5
pkgs/README.md doc/outputs/pkgs.md
··· 1 1 # Packages 2 - Similar to [modules](../modules), the pkgs directory mirrors the upstream 2 + Similar to [modules](./modules.md), the pkgs directory mirrors the upstream 3 3 [nixpkgs/pkgs][pkgs], and for the same reason; if you ever want to upstream 4 4 your package, it's as simple as dropping it into the nixpkgs/pkgs directory. 5 5 ··· 12 12 the supported systems listed in the package's `meta.platforms` attribute. 13 13 14 14 And, as usual, every package in the overlay is also available to any NixOS 15 - [host](../hosts). 15 + [host](../concepts/hosts.md). 16 16 17 17 ## Automatic Source Updates 18 18 There is the added, but optional, convenience of declaring your sources in 19 19 _pkgs/flake.nix_ as an input. You can then access them from the `srcs` package. 20 20 This allows updates to be managed automatically by simply 21 - [updating](../doc/flk/update.md#updating-package-sources) the lock file. No 21 + [updating](../flk/update.md#updating-package-sources) the lock file. No 22 22 more manually entering sha256 hashes! 23 23 24 24 As an added bonus, version strings are also generated automatically from either 25 - the flake ref, or the date and git revision of the source. For examples, 26 - definitely checkout the [community branch](../#community-profiles). 25 + the flake ref, or the date and git revision of the source. 27 26 28 27 ## Example 29 28 pkgs/development/libraries/libinih/default.nix:
+5 -5
profiles/README.md doc/concepts/profiles.md
··· 12 12 For the sake of consistency, a profile should always be defined in a 13 13 ___default.nix___ containing a [nixos module config][config]. 14 14 A profile's directory is used for quick modularization of 15 - [interelated bits](./#subprofiles). 15 + [interelated bits](./profiles.md#subprofiles). 16 16 17 17 > ##### _Notes:_ 18 - > * For _declaring_ module options, there's the [modules](../modules) directory. 18 + > * For _declaring_ module options, there's the [modules](../outputs/modules.md) directory. 19 19 > * This directory takes inspiration from 20 20 > [upstream](https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/profiles) 21 21 > . 22 22 > * Sticking to a simple [spec][spec] has refreshing advantages. 23 - > [hercules-ci](../doc/integrations/hercules.md) expects all profiles to be 23 + > [hercules-ci](../integrations/hercules.md) expects all profiles to be 24 24 > defined in a ___default.nix___, allowing them to be built automatically when 25 - > added. Congruently, [suites](../suites) expect ___default.nix___ to avoid 25 + > added. Congruently, [suites](suites.md) expect ___default.nix___ to avoid 26 26 > having to manage their paths manually. 27 27 28 28 ## Subprofiles ··· 56 56 Profiles are the most important concept in DevOS. They allow us to keep our 57 57 Nix expressions self contained and modular. This way we can maximize reuse 58 58 across hosts while minimizing boilerplate. Remember, anything machine 59 - specific belongs in your [host](../hosts) files instead. 59 + specific belongs in your [host](hosts.md) files instead. 60 60 61 61 [definition]: https://nixos.org/manual/nixos/stable/index.html#sec-option-definitions 62 62 [declaration]: https://nixos.org/manual/nixos/stable/index.html#sec-option-declarations
+2 -1
profiles/core/default.nix
··· 2 2 let inherit (lib) fileContents; 3 3 in 4 4 { 5 + imports = [ ../cachix ]; 5 6 6 7 nix.systemFeatures = [ "nixos-test" "benchmark" "big-parallel" "kvm" ]; 7 8 ··· 76 77 ''; 77 78 78 79 # fix nixos-option 79 - nixos-option = "nixos-option -I nixpkgs=${toString ../../compat}"; 80 + nixos-option = "nixos-option -I nixpkgs=${toString ../../lib/compat}"; 80 81 81 82 # sudo 82 83 s = ifSudo "sudo -E ";
secrets/README.md doc/secrets.md
+1 -1
shell.nix
··· 1 - (import ./compat).shellNix 1 + (import ./lib/compat).shellNix
+2
suites/README.md doc/concepts/suites.md
··· 6 6 In the future, we will use suites as a mechanism for deploying various machine 7 7 types which don't depend on hardware, such as vm's and containers. 8 8 9 + They are defined in `profiles/suites.nix`. 10 + 9 11 ## Definition 10 12 ```nix 11 13 rec {
suites/default.nix profiles/suites.nix
theme/highlight.js doc/theme/highlight.js
+6 -4
users/README.md doc/concepts/users.md
··· 1 1 # Users 2 2 3 - Users are a special case of [profiles](../profiles) that define system 3 + Users are a special case of [profiles](profiles.md) that define system 4 4 users and [home-manager][home-manager] configurations. For your convenience, 5 5 home manager is wired in by default so all you have to worry about is declaring 6 6 your users. For a fully fleshed out example, check out the developers personal ··· 24 24 25 25 ## Home Manager 26 26 Home Manager support follows the same principles as regular nixos configurations. 27 - All modules defined in [user modules](./modules/module-list.nix) will be imported to 28 - Home Manager. All profiles are availabe in [suites](../suites/default.nix) as userProfiles. 27 + All modules defined in [user modules][modules-list] will be imported to 28 + Home Manager. All profiles are availabe in [suites][suites] as userProfiles. 29 29 The `userSuites` output will be available in your Home Manager Configuration as 30 30 the special argument, `suites`. 31 31 32 32 ## External Usage 33 33 You can easily use the defined home-manager configurations outside of NixOS 34 - using the `homeConfigurations` flake output. The [flk](../doc/flk) helper 34 + using the `homeConfigurations` flake output. The [flk](../flk/index.md) helper 35 35 script makes this even easier. 36 36 37 37 This is great for keeping your environment consistent across Unix systems, ··· 56 56 ``` 57 57 58 58 [home-manager]: https://nix-community.github.io/home-manager 59 + [suites]: https://github.com/divnix/devos/tree/core/suites/default.nix 60 + [modules-list]: https://github.com/divnix/devos/tree/core/modules/module-list.nix