6 Matching Annotations
  1. May 2021
    1. The command nix-shell will build the dependencies of the specified derivation, but not the derivation itself. It will then start an interactive shell in which all environment variables defined by the derivation path have been set to their corresponding values, and the script $stdenv/setup has been sourced. This is useful for reproducing the environment of a derivation for development.

      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?

      <sup>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.</sup>

      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:

      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)

  2. Feb 2021
    1. A Nix expression describes everything that goes into a package build action (a “derivation”)

      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:


      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...

    2. For each output declared in outputs, the corresponding environment variable is set to point to the intended path in the Nix store for that output. Each output path is a concatenation of the cryptographic hash of all build inputs, the name attribute and the output name. (The output name is omitted if it’s out.)

      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?

    3. A derivation causes that derivation to be built prior to the present derivation; its default output path is put in the environment variable.

      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.
    4. derivationA description of a build action. The result of a derivation is a store object. 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).

      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).

  3. Oct 2019
    1. This option is a function which accepts a package as a parameter, and returns a boolean. The following example configuration accepts a package and always returns false: { allowUnfreePredicate = (pkg: false); }

      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.