1. 11
  1.  

  2. 4

    The terminology is a bit off in this post. Maybe the wording is just imprecise, but the diagram seems imply some misunderstandings (e.g., the author seems to equate a derivation with an output path).

    A Nix expression results in a derivation, which is a build of the expression,

    Evaluating certain kinds of expressions result in a derivation, which is really just an attrset with specific set of attributes. However, in certain contexts (e.g. the Nix REPL, nix-instantiate, etc.) this will result in a derivation file being created in the store. E.g.:

    ❯ nix repl '<nixpkgs>'
    nix-repl> :t hello
    a set
    nix-repl> builtins.attrNames hello
    [ "__ignoreNulls" "all" "args" "buildInputs" "builder" "configureFlags" "depsBuildBuild" "depsBuildBuildPropagated" "depsBuildTarget" "depsBuildTargetPropagated" "depsHostHost" "depsHostHostPropagated" "depsTargetTarget" "depsTargetTargetPropagated" "doCheck" "doInstallCheck" "drvAttrs" "drvPath" "inputDerivation" "meta" "name" "nativeBuildInputs" "out" "outPath" "outputName" "outputUnspecified" "outputs" "override" "overrideAttrs" "overrideDerivation" "passthru" "patches" "pname" "propagatedBuildInputs" "propagatedNativeBuildInputs" "src" "stdenv" "strictDeps" "system" "type" "userHook" "version" ]
    nix-repl> hello
    «derivation /nix/store/ry2xir6crppncm1niprgijhsbxl3dmrk-hello-2.10.drv»
    

    The derivation can be built and that results in an output path:

    ❯ nix-build /nix/store/ry2xir6crppncm1niprgijhsbxl3dmrk-hello-2.10.drv
    /nix/store/8a6lbpbxbc5lc60ljwhw69sszr25ys5f-hello-2.10
    

    that takes some inputs and produces an output, outputs are almost always some /nix/store/some-hash-pkg-name path.

    The derivations do not take inputs (in the sense that a function takes inputs), the paths of dependencies are already fully realized in the derivations.

    But there are a lot of things that we don’t know about the file that’s there, for example:

    What’s the version of the package the binary/library came from? What are the libraries it uses? What configure flags were enabled during the build?

    In most other package managers, all these questions except perhaps the last can be answered using a simple query.

    Also, using Nix, you wouldn’t be able to answer the third question with just an output path, you’d need the original expression or derivation. You can query the deriver, but if it is already garbage collected [1], you either need to original expression or the derivation must in the binary cache.

    You may also not be able to answer the first question, since you can set the name attribute to something that does not contain the version. That may sound malicious, but many e.g. some fetchers just use generic names for their output (e.g. fetchFromGitHub).

    [1] You can configure Nix such that is does not GC derivations for output paths that are not GCed.