Great, so r-balance of p is derived by the history of ops regarding r. So no need for p to calculate it and add to every op, would be redundant. Not sure the derivation is the proposed protocol though.

QUESTION: What exactly does nix-shell execute from the Nix expression (i.e., shell.nix, default.nix, etc.)?

ANSWER: Based on my current understanding, the answer is everything. It calls $stdenv/setup (see annotation below) to set up the most basic environment variables (TODO: expand on this), and "injects" the most common tools (e.g., gcc, sed) into it.

It also defines the phases (TODO: verify this) and builder functions, such as genericBuilder. For example, the default builder is just two lines:

source $stdenv/setup
genericBuild

TODO: pkgs/stdenv/generic/builder.sh is a mystery though.

QUESTION: Once dropping into nix-shell, how do I know what phases to execute by looking at a default.nix? (E.g., [..]freeswitch/default.nix)

ANSWER: As far as I can tell, one can override the phases in their Nix build expression (to build the derivation, see at the bottom), but they won't get executed as only the $stdenv/setup (see above) will get sourced, and no builders are called that, in return, invoke the phases (again, see above).

So if one is using nix-shell

• to create/hack on a package, the person has to manually invoke the builder or phases (TODO: still fuzzy on this subject)

• to set up an environment, then one doesn't even have to worry about builders/phases because we just use nix-shell to clear the environment and to inject tools that we need for a given task

QUESTION: When dropping into nix-shell, is this Nix expression (i.e., freeswitch/default.nix) executed? Or just parts of it?

ANSWER: As stated above, all of the input Nix expression is evaluated, but no builders and build phases are called; although, nothing prevents one to override the phases, in case they are creating/hacking on a package.

QUESTION:

The command nix-shell will build the dependencies of the specified derivation, but not the derivation itself.

What is the "derivation" here exactly? I know that it is a build expression, but does that mean the default.nix (or other Nix expression) nix-shell is invoked with?

^{This statement also seems like a contradiction with how `nix-shell` works (i.e., if one issues `nix-shell -p curl`, then `curl` will be available in that sub-shell), but `-p` acts like a shortcut to as if `curl` had been listed in `buildInputs` so this is not the case.}

ANSWER: I have the feeling my confusion comes from the fact that the term "derivation" is used ambiguously in the manuals, sometimes to mean multiple things (see list below).

TODO: Substantiate this claim, and make sure that it not coming from my misunderstanding certain topics.

• Nix build expression (such as default.nix) whose output is going to become the store derivation itself (see last item at the bottom about the Nix manual's glossary definition)

• store derivation.

Had multiple cracks at unambiguously define what a derivation is, and here's a list of these:

• What is the purpose of nix-instantiate? What is a store-derivation? (probably the best try yet)

• What is a Nix expression in regard to Nix package management? (feels sloppier, but commenter mentions ATerm, adding the possibility of making it very specific)

• Closure vs derivation in the Nix package manager (very short, and will have to be re-written, but adds closures to the mix)

• There is now a glossary definition of a derivation in the Nix manual; see this annotation why I find it problematic

QUESTION: What is the difference between nix-shell -p and nix-shell invoked with a Nix expression of mkShell (or other that achieves the similar effect)?

QUESTION: nix-shell does not create a sub-shell, so what does it do? (clarification: so nix-shell indeed does it; I confused it with nix shell)

Come up with an ultimate definition for what a "derivation" is.

So round up all the places where it is mentioned across Nix* manuals, and check out these:

• https://stackoverflow.com/questions/58243554/what-is-a-nix-expression-in-regard-to-nix-package-management (this also needs to be edited)

• https://stackoverflow.com/questions/31490262/what-is-the-purpose-of-nix-instantiate-what-is-a-store-derivation

• https://nixos.org/manual/nix/unstable/expressions/derivations.html

• https://github.com/justinwoo/nix-shorts/blob/master/posts/your-first-derivation.md

• look for more online

From Nix Pills section 6.1. The derivation function (see annotation):

A derivation from a Nix language view point is simply a set, with some attributes. Therefore you can pass the derivation around with variables like anything else.

So there is clearly an ambiguity between what derivations are perceived to be and what is stated in the Eelco Dolstra's PhD thesis. Or maybe I'm having issues with reading comprehension again...

QUESTION: So when I see $out in a builder script, it refers to the default output path because the output attribute in the Nix expression has never been explicitly set, right?

That is, if an input attribute is a reference to a derivation in the Nix store, then

1. that derivation is built first (after a binary substitute is not found, I presume), and
2. the path to the built package (for a better word) is handed to the shell build script.

Organically related to the annotation regarding my nix-shell confusion.

The dissection of this definition to show why I find it lacking:

A description of a build action.

The first (couple) time(s) I read the manuals, this description popped up in many places, and I identified it with Nix expression every time, thinking that a derivation is a synonym for Nix expression.

Maybe it is, because it clearly tries to disambiguate between store derivations and derivation in the last sentence.

The result of a derivation is a store object.

Is this store object the same as a store derivation?

Derivations are typically specified in Nix expressions using the `derivation primitive. These are translated into low-level store derivations (implicitly by nix-env and nix-build, or explicitly by nix-instantiate).

QUESTION: So, the part of the Nix build expression (such as default.nix) where the derivation primitive is called (explicitly or implicitly, as in mkDerivation) is the derivation, that will be ultimately be translated into store derivations?

ANSWER: Start at section 15.4 Derivation.

QUESTION: Also, why is typically used here? Can one define derivations outside of Nix expressions?

ANSWER(?): One could I guess, because store derivations are ATerms (see annotation at the top), and the Nix expression language is just a tool to translate parameterized build actions into concrete terms to build a software package. The store derivations could be achieved using different means; e.g., the way Guix uses Guile scheme to get the same result))

I believe, that originally, derivation was simply a synonym to store derivation. Maybe it still is, and I'm just having difficulties with reading comprehension but I think the following would be less misleading (to me and apart from re-writing the very first sentence):

Derivations are typically the result of Nix expressions calling the derivation primitive explicitly, or implicitly usingmkDerivation`. These are translated into low-level store derivations (implicitly by nix-env and nix-build, or explicitly by nix-instantiate).

See main annotation for the derivation topic

QUESTION: So the Nix store houses derivations and not the built packages?

QUESTION: Are the hashes in the Nix store not unique?

Doesn't really say anything but thought it important to highlight this first mention of derivations in the Nix Pills.

public keys included in key derivation.

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.