This is vague to the point of being useless, given the Nix expression language is untyped.

A snippet from freeswitch.nix:

      configTemplate = mkOption {
        type = types.path;
        # omitted
      };
      configDir = mkOption {
        type = with types; attrsOf path;
        # omitted
      };

• Where does types come from?

  See NixOS manual at "Option types".

• What is the difference between the path types? (I guess, the second one is attribute set consisting only of paths.)

TODO: document lib.mkIf

Found a description in the NixOS manual:

The special function mkIf causes the evaluation of the conditional to be “pushed down” into the individual definitions, as if you had written:

config = {
  environment.systemPackages = if
config.services.httpd.enable then [ ... ] else [];
  ...
};

TODO: document lib.mkDefault

Not mentioned in any of the manuals (i.e., nix, nixpkgs, NixOS), only the NixOS options page has 1 mention:

Some promising search result (in the order of relevance):

• https://releases.nixos.org/nix-dev/2015-June/017549.html
• https://releases.nixos.org/nix-dev/2015-June/017549.html

From source:

  mkOverride = priority: content:
    { _type = "override";
      inherit priority content;
    };

  mkDefault = mkOverride 1000; # used in config sections of non-user modules to set a default

It seems that all the mkOverride calls set up a priority for certain actions.

What is an option?

From the link below to the source, it's just an attribute set with all the function parameters (see below) plus a _type attribute name to allow for type level operations (because Nix is untyped).

  mkOption =
    {
    # Default value used when no definition is given in the configuration.
    default ? null,
    # Textual representation of the default, for the manual.
    defaultText ? null,
    # Example value used in the manual.
    example ? null,
    # String describing the option.
    description ? null,
    # Related packages used in the manual (see `genRelatedPackages` in ../nixos/lib/make-options-doc/default.nix).
    relatedPackages ? null,
    # Option type, providing type-checking and value merging.
    type ? null,
    # Function that converts the option value to something else.
    apply ? null,
    # Whether the option is for NixOS developers only.
    internal ? null,
    # Whether the option shows up in the manual.
    visible ? null,
    # Whether the option can be set only once
    readOnly ? null,
    # Deprecated, used by types.optionSet.
    options ? null
    } @ attrs:
    attrs // { _type = "option"; };

How does it fit in a big scheme of things?

?

If there is recursiveUpdateUntil (i.e., mergeUntil) then mergeWith would also be welcome.

Would be nice to have an alias called merge.

Fix: add semicolon after last Any. (same above in the main type signature)

So the type signature

(String -> Any -> Any) -> AttrSet -> Any
                                     ^^^

should be

(String -> Any -> Any) -> AttrSet -> List
                                     ^^^^

instead, right?

See comment above.

Then why not call it collectVals?... (Following the distinctive naming convention between lib.attrsets.attrVals and lib.attrsets.attrValues.)

Especially because there is lib.attrsets.collect:

catAttrs :: String -> [AttrSet] -> [Any]
collect :: (Any -> Bool) -> AttrSet -> [Any]

(Call it filterVals? There are filterAttrs* functions but those return an attribute set, so no collision.)

This should read "Attribute Set Functions". Nowhere else is attribute sets spelled as "attribute-set".

edit: Alright, "attribute-set" is used in total of 4 times, whereas "attribute set" is used 112 times.

works both on strings and paths

Path concatenation as well: https://gist.github.com/CMCDragonkai/de84aece83f8521d087416fa21e34df4

Bonus: https://stackoverflow.com/questions/43850371/when-does-a-nix-path-type-make-it-into-the-nix-store-and-when-not

This can be written up in many other forms, plus the possibility of currying deserves to be pointed out:

$ nix repl
nix-repl> (sq: (x: y: sq y + sq x) 2 7) (x: x*x)
53

nix-repl> (sq: (x: y: sq y + sq x)) (x: x*x)     
«lambda @ (string):1:11»

nix-repl> (sq: (x: y: sq y + sq x)) (x: x*x) 2
«lambda @ (string):1:14»

nix-repl> (sq: (x: y: sq y + sq x)) (x: x*x) 2 7
53

nix-repl> (sq: x: y: sq y + sq x) (x: x*x) 2 7   
53

Or use the Nix package manager's nix-shell.

• https://toraritte.github.io/posts/2020-07-15-nix-shell-with-specific-path.html
• https://stackoverflow.com/a/62923700/1498178

There is hnix that is still actively developed (as of 2020/06/21).

It is kind of an anti-pattern using the angle bracket notation and the linked post also makes a suggestion:

{ pkgs ? import (fetchTarball https://github.com/NixOS/nixpkgs/archive/3590f02e7d5760e52072c1a729ee2250b5560746.tar.gz) {};
}:
# ...

It is kind of an anti-pattern using the angle bracket notation and the linked post also makes a suggestion:

{ pkgs ? import (fetchTarball https://github.com/NixOS/nixpkgs/archive/3590f02e7d5760e52072c1a729ee2250b5560746.tar.gz) {};
}:
# ...

It is kind of an anti-pattern using the angle bracket notation and the linked post also makes a suggestion:

{ pkgs ? import (fetchTarball https://github.com/NixOS/nixpkgs/archive/3590f02e7d5760e52072c1a729ee2250b5560746.tar.gz) {};
}:
# ...

What is the difference between the vim and vim_configurable packages?

I believe the source for the latter is here.

This will still work on 20.03 but will show a warning as name = "root"; is deprecated, and luksroot should be used instead (see boot.initrd.luks.devices NixOS option) .

boot.initd.luks.devices = {
  luksroot = {
    device = "/nev/sda2";
    preLVM = true;
  };
};

The Nixpkgs pull request template has a checkbox "Determined the impact on package closure size (by running nix path-info -S before and after)" but there is only 4 instances of path-info in the Nix manual (and none in the Nixpkgs manual).

nix --help says

path-info        query information about store paths

so the command works at the bottom but what switches are available for example? From the examples, -r and -S is valid but where are they documented?

nix path-info -rS $(readlink -f $(which vim))

Docker based PHP development environment

Nix ecosystem introduction ("Talk at my company")

Declarative package management for normal users

What is the relationship between Disnix and NixOps?

NIX + BAZEL = FULLY REPRODUCIBLE, INCREMENTAL BUILDS

Web Hosting with IPFS and Nix

How we use Nix at IOHK?

Why is rec needed here, and not in the example under 2.6.1?

Based on what I saw with other examples, rec is usually included when a_package.override is used inside packageOverrides. But why?

The entire chapter 3 is worth reading. Great resource on what a package (or more broadly, a component) is in regards to Nix.

Specifically "3.1 What is a component?"

There is no officially prescribed reading order of the Nix manuals, but it's safe to say that one should start this, the Nix manual. Then it would be prudent to briefly describe what a package is in the context of Nix and/or (at east) link to the definition.

I like how Dolstra's thesis has an entire section on the topic (that is, on the more general concept of components).

It is clear now that there can be multiple versions of the same package in the store, but how does one call them (e.g., if is an executable application)? Simply by using the full Nix store path (and create and manage one's own symlinks, with stow or manually)??

haskell-overridez is a tool and library of nix functions that simplify the use of overrides while developing haskell projects with nixpkgs.

A nix-based Haskell project manager

Eelco Dolstra's seminal paper

"fixed-point", "fix point" seems to be most important concept in Nix, because overrides, overridePackages, overlays are built using it.

• Nix Pill - Chapter 17. Nixpkgs Overriding Packages (the first place I saw this concept properly described)
• Nixpkgs issue - Add pkgs.overrideWithScope#44196 (best high level summary of Nixpkgs ever read)
• How to Fake Dynamic Binding in Nix
• Comment by zimbatm on NixOS Discourse
• nixpkgs/lib/fixed-points.nix

• [Nix-dev] Introducing Nixpkgs Overlays
• Video - Initial announcement of overlays by Nicolas B. Pierron (nbp)
• Overlays implementation by Nicolas B. Pierron (nbp)
• https://nixos.wiki/wiki/Overlays
• Gabriel439/haskell-nix issue #58
• NixOS: The DOs and DON’Ts of nixpkgs overlays
• Nix overlays and override pattern Stackoverflow thread

Should packageOverrides be deprecated in favor of Overlays?

• Nixpkgs issue - Deprecate packageOverrides? #43266
• Nixpkgs pull request - [WIP] Deprecate packageOverrides #43560

Where is buildEnv documented?

• How buildEnv builtin function works? Stackoverflow thread
• mkShell vs. buildEnv?
• NixOS Wiki, Documentation Gaps, section What's the relationship between nix-env and buildEnv
• How to copy a nix-env profile using nix-copy-closure?
• https://news.ycombinator.com/item?id=11803558

Find out where stdenv.lib functions are documented.

builtins.elem x xs

Return true if a value equal to x occurs in the list xs, and false otherwise.

builtins.parseDrvName s

Split the string s into a package name and version. The package name is everything up to but not including the first dash followed by a digit, and the version is everything following that dash. The result is returned in a set { name, version }. Thus, builtins.parseDrvName "nix-0.12pre12876" returns { name = "nix"; version = "0.12pre12876"; }.

What is a package in this context? That is, the callback's pkg parameter. Is it a derivation?

If I understood it correctly, whenever referencing other packages as inputs, those are actually derivations, that are just attribute sets.

Here's a Rolling Stone article on the matter.

His Wikipedia page is here.