build(deps): bump technote-space/get-diff-action from v2.0.2 to v4

.editorconfig

@@ -54,9 +54,15 @@ end_of_line = unset
 [*.lock]
 indent_size = unset
 
+[deps.nix]
+insert_final_newline = unset
+
 [gemset.nix]
 insert_final_newline = unset
 
+[node-packages.nix]
+insert_final_newline = unset
+
 [pkgs/applications/editors/emacs-modes/recipes-archive-melpa.json]
 indent_size = unset
 

.github/CODEOWNERS

@@ -10,6 +10,12 @@
 # This file
 /.github/CODEOWNERS @edolstra
 
+# GitHub actions
+/.github/workflows @Mic92 @zowoq
+
+# EditorConfig
+/.editorconfig @Mic92 @zowoq
+
 # Libraries
 /lib                        @edolstra @nbp @infinisil
 /lib/systems                @nbp @ericson2314 @matthewbauer

.github/workflows/editorconfig.yml

@@ -1,19 +1,21 @@
-name: actions
+name: "Checking EditorConfig"
 
 on:
   pull_request:
     branches:
       - master
 
 jobs:
-  editorconfig:
+  tests:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v2
-    - uses: technote-space/get-diff-action@v2.0.2
-    - name: editorconfig check
+      with:
+        fetch-depth: 0
+    - uses: technote-space/get-diff-action@v4
+    - name: Checking EditorConfig
       env:
-        VERSION: "2.0.4"
+        VERSION: "2.1.0"
         OS: "linux"
         ARCH: "amd64"
       run: |

doc/languages-frameworks/go.xml

@@ -40,6 +40,8 @@ pet = buildGoModule rec {
 
   subPackages = [ "." ]; <co xml:id='ex-buildGoModule-2' />
 
+  runVend = true; <co xml:id='ex-buildGoModule-3' />
+
   meta = with lib; {
     description = "Simple command-line snippet manager, written in Go";
     homepage = "https://github.com/knqyf263/pet";
@@ -66,7 +68,7 @@ pet = buildGoModule rec {
     </callout>
     <callout arearefs='ex-buildGoModule-3'>
      <para>
-         <varname>runVend</varname> runs the vend command to generate the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build.
+      <varname>runVend</varname> runs the vend command to generate the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build.
      </para>
     </callout>
    </calloutlist>

lib/generators.nix

@@ -48,8 +48,10 @@ rec {
     else if isAttrs    v then err "attrsets" v
     # functions can’t be printed of course
     else if isFunction v then err "functions" v
-    # let’s not talk about floats. There is no sensible `toString` for them.
-    else if isFloat    v then err "floats" v
+    # Floats currently can't be converted to precise strings,
+    # condition warning on nix version once this isn't a problem anymore
+    # See https://github.com/NixOS/nix/pull/3480
+    else if isFloat    v then libStr.floatToString v
     else err "this value is" (toString v);
 
 

lib/strings.nix

@@ -612,6 +612,22 @@ rec {
   */
   fixedWidthNumber = width: n: fixedWidthString width "0" (toString n);
 
+  /* Convert a float to a string, but emit a warning when precision is lost
+     during the conversion
+
+     Example:
+       floatToString 0.000001
+       => "0.000001"
+       floatToString 0.0000001
+       => trace: warning: Imprecise conversion from float to string 0.000000
+          "0.000000"
+  */
+  floatToString = float: let
+    result = toString float;
+    precise = float == builtins.fromJSON result;
+  in if precise then result
+    else lib.warn "Imprecise conversion from float to string ${result}" result;
+
   /* Check whether a value can be coerced to a string */
   isCoercibleToString = x:
     builtins.elem (builtins.typeOf x) [ "path" "string" "null" "int" "float" "bool" ] ||

maintainers/maintainer-list.nix

@@ -833,6 +833,12 @@
     githubId = 135230;
     name = "Aycan iRiCAN";
   };
+  artturin = {
+    email = "artturin@artturin.com";
+    github = "artturin";
+    githubId = 56650223;
+    name = "Artturi N";
+  };
   b4dm4n = {
     email = "fabianm88@gmail.com";
     github = "B4dM4n";
@@ -1930,6 +1936,12 @@
     githubId = 14032;
     name = "Daniel Brockman";
   };
+  ddelabru = {
+    email = "ddelabru@redhat.com";
+    github = "ddelabru";
+    githubId = 39909293;
+    name = "Dominic Delabruere";
+  };
   dduan = {
     email = "daniel@duan.ca";
     github = "dduan";
@@ -4151,6 +4163,12 @@
     github = "karantan";
     githubId = 7062631;
   };
+  KarlJoad = {
+    email = "karl@hallsby.com";
+    github = "KarlJoad";
+    githubId = 34152449;
+    name = "Karl Hallsby";
+  };
   karolchmist = {
     email = "info+nix@chmist.com";
     name = "karolchmist";
@@ -5175,6 +5193,12 @@
     githubId = 13689192;
     name = "Nguyễn Gia Phong";
   };
+  mcwitt = {
+    email = "mcwitt@gmail.com";
+    github = "mcwitt";
+    githubId = 319411;
+    name = "Matt Wittmann";
+  };
   mdaiter = {
     email = "mdaiter8121@gmail.com";
     github = "mdaiter";
@@ -7480,6 +7504,12 @@
     githubId = 2770647;
     name = "Simon Vandel Sillesen";
   };
+  siraben = {
+    email = "bensiraphob@gmail.com";
+    github = "siraben";
+    githubId = 8219659;
+    name = "Siraphob Phipathananunth";
+  };
   siriobalmelli = {
     email = "sirio@b-ad.ch";
     github = "siriobalmelli";

nixos/doc/manual/development/settings-options.xml

@@ -0,0 +1,179 @@
+<section xmlns="http://docbook.org/ns/docbook"
+        xmlns:xlink="http://www.w3.org/1999/xlink"
+        xmlns:xi="http://www.w3.org/2001/XInclude"
+        version="5.0"
+        xml:id="sec-settings-options">
+ <title>Options for Program Settings</title>
+
+ <para>
+   Many programs have configuration files where program-specific settings can be declared. File formats can be separated into two categories:
+   <itemizedlist>
+     <listitem>
+       <para>
+         Nix-representable ones: These can trivially be mapped to a subset of Nix syntax. E.g. JSON is an example, since its values like <literal>{"foo":{"bar":10}}</literal> can be mapped directly to Nix: <literal>{ foo = { bar = 10; }; }</literal>. Other examples are INI, YAML and TOML. The following section explains the convention for these settings.
+       </para>
+     </listitem>
+     <listitem>
+       <para>
+         Non-nix-representable ones: These can't be trivially mapped to a subset of Nix syntax. Most generic programming languages are in this group, e.g. bash, since the statement <literal>if true; then echo hi; fi</literal> doesn't have a trivial representation in Nix.
+       </para>
+       <para>
+         Currently there are no fixed conventions for these, but it is common to have a <literal>configFile</literal> option for setting the configuration file path directly. The default value of <literal>configFile</literal> can be an auto-generated file, with convenient options for controlling the contents. For example an option of type <literal>attrsOf str</literal> can be used for representing environment variables which generates a section like <literal>export FOO="foo"</literal>. Often it can also be useful to also include an <literal>extraConfig</literal> option of type <literal>lines</literal> to allow arbitrary text after the autogenerated part of the file.
+       </para>
+     </listitem>
+   </itemizedlist>
+ </para>
+ <section xml:id="sec-settings-nix-representable">
+   <title>Nix-representable Formats (JSON, YAML, TOML, INI, ...)</title>
+   <para>
+     By convention, formats like this are handled with a generic <literal>settings</literal> option, representing the full program configuration as a Nix value. The type of this option should represent the format. The most common formats have a predefined type and string generator already declared under <literal>pkgs.formats</literal>:
+     <variablelist>
+       <varlistentry>
+         <term>
+           <varname>pkgs.formats.json</varname> { }
+         </term>
+         <listitem>
+           <para>
+             A function taking an empty attribute set (for future extensibility) and returning a set with JSON-specific attributes <varname>type</varname> and <varname>generate</varname> as specified <link linkend='pkgs-formats-result'>below</link>.
+           </para>
+         </listitem>
+       </varlistentry>
+       <varlistentry>
+         <term>
+           <varname>pkgs.formats.yaml</varname> { }
+         </term>
+         <listitem>
+           <para>
+             A function taking an empty attribute set (for future extensibility) and returning a set with YAML-specific attributes <varname>type</varname> and <varname>generate</varname> as specified <link linkend='pkgs-formats-result'>below</link>.
+           </para>
+         </listitem>
+       </varlistentry>
+       <varlistentry>
+         <term>
+           <varname>pkgs.formats.ini</varname> { <replaceable>listsAsDuplicateKeys</replaceable> ? false, ... }
+         </term>
+         <listitem>
+           <para>
+             A function taking an attribute set with values
+             <variablelist>
+               <varlistentry>
+                 <term>
+                   <varname>listsAsDuplicateKeys</varname>
+                 </term>
+                 <listitem>
+                   <para>
+                     A boolean for controlling whether list values can be used to represent duplicate INI keys
+                   </para>
+                 </listitem>
+               </varlistentry>
+             </variablelist>
+            It returns a set with INI-specific attributes <varname>type</varname> and <varname>generate</varname> as specified <link linkend='pkgs-formats-result'>below</link>.
+           </para>
+         </listitem>
+       </varlistentry>
+       <varlistentry>
+         <term>
+           <varname>pkgs.formats.toml</varname> { }
+         </term>
+         <listitem>
+           <para>
+             A function taking an empty attribute set (for future extensibility) and returning a set with TOML-specific attributes <varname>type</varname> and <varname>generate</varname> as specified <link linkend='pkgs-formats-result'>below</link>.
+           </para>
+         </listitem>
+       </varlistentry>
+     </variablelist>
+
+   </para>
+   <para xml:id="pkgs-formats-result">
+     These functions all return an attribute set with these values:
+    <variablelist>
+      <varlistentry>
+        <term>
+          <varname>type</varname>
+        </term>
+        <listitem>
+          <para>
+            A module system type representing a value of the format
+          </para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term>
+          <varname>generate</varname> <replaceable>filename</replaceable> <replaceable>jsonValue</replaceable>
+        </term>
+        <listitem>
+          <para>
+           A function that can render a value of the format to a file. Returns a file path.
+           <note>
+            <para>
+             This function puts the value contents in the Nix store. So this should be avoided for secrets.
+            </para>
+           </note>
+          </para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+   </para>
+   <example xml:id="ex-settings-nix-representable">
+     <title>Module with conventional <literal>settings</literal> option</title>
+     <para>
+       The following shows a module for an example program that uses a JSON configuration file. It demonstrates how above values can be used, along with some other related best practices. See the comments for explanations.
+     </para>
+<programlisting>
+{ options, config, lib, pkgs, ... }:
+let
+  cfg = config.services.foo;
+  # Define the settings format used for this program
+  settingsFormat = pkgs.formats.json {};
+in {
+
+  options.services.foo = {
+    enable = lib.mkEnableOption "foo service";
+
+    settings = lib.mkOption {
+      # Setting this type allows for correct merging behavior
+      type = settingsFormat.type;
+      default = {};
+      description = ''
+        Configuration for foo, see
+        &lt;link xlink:href="https://example.com/docs/foo"/&gt;
+        for supported values.
+      '';
+    };
+  };
+
+  config = lib.mkIf cfg.enable {
+    # We can assign some default settings here to make the service work by just
+    # enabling it. We use `mkDefault` for values that can be changed without
+    # problems
+    services.foo.settings = {
+      # Fails at runtime without any value set
+      log_level = lib.mkDefault "WARN";
+
+      # We assume systemd's `StateDirectory` is used, so we require this value,
+      # therefore no mkDefault
+      data_path = "/var/lib/foo";
+
+      # Since we use this to create a user we need to know the default value at
+      # eval time
+      user = lib.mkDefault "foo";
+    };
+
+    environment.etc."foo.json".source =
+      # The formats generator function takes a filename and the Nix value
+      # representing the format value and produces a filepath with that value
+      # rendered in the format
+      settingsFormat.generate "foo-config.json" cfg.settings;
+
+    # We know that the `user` attribute exists because we set a default value
+    # for it above, allowing us to use it without worries here
+    users.users.${cfg.settings.user} = {}
+
+    # ...
+  };
+}
+</programlisting>
+   </example>
+ </section>
+
+</section>

nixos/doc/manual/development/writing-modules.xml

@@ -183,4 +183,5 @@ in {
  <xi:include href="meta-attributes.xml" />
  <xi:include href="importing-modules.xml" />
  <xi:include href="replace-modules.xml" />
+ <xi:include href="settings-options.xml" />
 </chapter>