@@ -176,7 +176,7 @@ argument that gets passed to your home-manager users.Note:
-This section and its semantics need a conceptiual rework. +
This section and its semantics need a conceptiual rework. Since recently portable home configurations that are not bound to any specific host are a thing.
External Usage
You can easily use the defined home-manager configurations outside of NixOS
-using the homeConfigurations flake output.
homeConfigurations flake output.
This is great for keeping your environment consistent across Unix-like systems, including macOS.
# build
diff --git a/index.html b/index.html
index aeba050..e6f8222 100644
--- a/index.html
+++ b/index.html
@@ -214,7 +214,7 @@ join the chat or report prob
To craft well thought out APIs we need all the thoughts regarding new ideas.
Pull Requests are just as amazing.
Why flakes?
-Flakes are a part of an explicit push to improve Nix's UX, and have become an integral part of that effort.
+Flakes are a part of an explicit push to improve Nix's UX, and have become an integral part of that effort.
They also make Nix expressions easier to distribute and reuse with convient flake references for building or using packages, modules, and whole systems.
Shoulders
This work does not reinvent the wheel. It stands on the shoulders of the
diff --git a/integrations/deploy.html b/integrations/deploy.html
index 7effdbe..d320f4a 100644
--- a/integrations/deploy.html
+++ b/integrations/deploy.html
@@ -193,7 +193,7 @@ deploy.nodes = digga.lib.mkDeployNodes self.nixosConfigurations
};
};
Substitute <HOSTNAME>, <HM_PROFILE> and <YOUR_USERNAME> placeholders (omitting the <>).
Substitute <HOSTNAME>, <HM_PROFILE> and <YOUR_USERNAME> placeholders (omitting the <>).
<ANOTHER_HM_PROFILE> is there to illustrate deploying multiple home-manager configurations. Either substitute those as well,
or remove them altogether. Don't forget the profileOrder variable.
meta.platforms attribute.
And, as usual, every package in the overlay is also available to any NixOS host.
-Another convenient difference is that it is possible to use -nvfetcher to keep packages up to +
Another convenient difference is that it is possible to use +nvfetcher to keep packages up to date. This is best understood by the simple example below.
Example
-It is possible to specify sources separately to keep them up to date semi +
It is possible to specify sources separately to keep them up to date semi automatically. The basic rules are specified in pkgs/sources.toml:
# nvfetcher.toml
@@ -158,7 +158,7 @@ The basic rules are specified in pkgs/sources.toml:
src.github = "benhoyt/inih"
fetch.github = "benhoyt/inih"
After changes to this file as well as to update the packages specified in there run +
After changes to this file as well as to update the packages specified in there run nvfetcher (for more details see nvfetcher).
The pkgs overlay is managed in pkgs/default.nix:
@@ -187,7 +187,7 @@ stdenv.mkDerivation {Migration from flake based approach
Previous to nvfetcher it was possible to manage sources via a pkgs/flake.nix, the main changes from there are that sources where in the attribute "srcs" (now "sources") and the contents of the sources where slightly different. In order to switch to the new system, rewrite pkgs/flake.nix to a pkgs/sources.toml file using the documentation of nvfetcher, -add the line that calls the sources at the beginning of pkgs/default.nix, and +add the line that calls the sources at the beginning of pkgs/default.nix, and accomodate the small changes in the packages as can be seen from the example.
The example package looked like:
pkgs/flake.nix:
diff --git a/print.html b/print.html index f4c0462..e139528 100644 --- a/print.html +++ b/print.html @@ -215,7 +215,7 @@ join the chat or report probTo craft well thought out APIs we need all the thoughts regarding new ideas.
Pull Requests are just as amazing.
Why flakes?
-Flakes are a part of an explicit push to improve Nix's UX, and have become an integral part of that effort.
+Flakes are a part of an explicit push to improve Nix's UX, and have become an integral part of that effort.
They also make Nix expressions easier to distribute and reuse with convient flake references for building or using packages, modules, and whole systems.
Shoulders
This work does not reinvent the wheel. It stands on the shoulders of the
@@ -385,7 +385,7 @@ of how any overlay can get channels as their first argument.
overlays/overrides.nix is the best place to consolidate all package
overrides and the property is already set for you.
Modules
-You can also pull modules from other channels. All modules have access to the +
You can also pull modules from other channels. All modules have access to the
modulesPath for each channel as <channelName>ModulesPath. And you can use
disabledModules to remove modules from the current channel.
To pull zsh module from the latest channel this code can be placed in any module, whether its your host file, a profile, or a module in ./modules etc:
Creation
Profiles are created with the rakeLeaves function which recursively collects
-.nix files from within a folder. The recursion stops at folders with a default.nix
+.nix files from within a folder. The recursion stops at folders with a default.nix
in them. You end up with an attribute set with leaves(paths to profiles) or
nodes(attrsets leading to more nodes or leaves).
A profile is used for quick modularization of interelated bits.
@@ -473,7 +473,7 @@ insuites are flattened and type-checked as paths.
@@ -513,7 +513,7 @@ argument that gets passed to your home-manager users.Note:
-This section and its semantics need a conceptiual rework. +
This section and its semantics need a conceptiual rework. Since recently portable home configurations that are not bound to any specific host are a thing.
External Usage
You can easily use the defined home-manager configurations outside of NixOS
-using the homeConfigurations flake output.
homeConfigurations flake output.
This is great for keeping your environment consistent across Unix-like systems, including macOS.
# build
@@ -624,12 +624,12 @@ which is defined as a simple overlay.
the supported systems listed in the package's meta.platforms attribute.
And, as usual, every package in the overlay is also available to any NixOS
host.
-Another convenient difference is that it is possible to use
-nvfetcher to keep packages up to
+
Another convenient difference is that it is possible to use
+nvfetcher to keep packages up to
date.
This is best understood by the simple example below.
Example
-It is possible to specify sources separately to keep them up to date semi
+
It is possible to specify sources separately to keep them up to date semi
automatically.
The basic rules are specified in pkgs/sources.toml:
# nvfetcher.toml
@@ -637,7 +637,7 @@ The basic rules are specified in pkgs/sources.toml:
src.github = "benhoyt/inih"
fetch.github = "benhoyt/inih"
-After changes to this file as well as to update the packages specified in there run
+
After changes to this file as well as to update the packages specified in there run
nvfetcher (for more details see nvfetcher).
The pkgs overlay is managed in
pkgs/default.nix:
@@ -666,7 +666,7 @@ stdenv.mkDerivation {
Migration from flake based approach
Previous to nvfetcher it was possible to manage sources via a pkgs/flake.nix, the main changes from there are that sources where in the attribute "srcs" (now "sources") and the contents of the sources where slightly different.
In order to switch to the new system, rewrite pkgs/flake.nix to a pkgs/sources.toml file using the documentation of nvfetcher,
-add the line that calls the sources at the beginning of pkgs/default.nix, and
+add the line that calls the sources at the beginning of pkgs/default.nix, and
accomodate the small changes in the packages as can be seen from the example.
The example package looked like:
pkgs/flake.nix:
@@ -884,7 +884,7 @@ deploy.nodes = digga.lib.mkDeployNodes self.nixosConfigurations
};
};
Substitute <HOSTNAME>, <HM_PROFILE> and <YOUR_USERNAME> placeholders (omitting the <>).
Substitute <HOSTNAME>, <HM_PROFILE> and <YOUR_USERNAME> placeholders (omitting the <>).
<ANOTHER_HM_PROFILE> is there to illustrate deploying multiple home-manager configurations. Either substitute those as well,
or remove them altogether. Don't forget the profileOrder variable.
nvfetcher
@@ -1227,11 +1227,11 @@ null or attribute set of list of paths or anything convertible to its or path comain./examples & ./e2e and wire test up in the devshell. ./examples & ./e2e and wire test up in the devshell.