lib.attrsets: Correct wrong documentation in getLib etc

[gabyx]

• Functions do not return a String but a Derivation.

Description of changes

Correct some small documentation issues.

---

Add a 👍 reaction to pull requests you find important.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/understanding-lib-attrsets-getlib/39324/3

[tobiasBora]

I think in the examples you want to add .drv at the end of all derivations:

nix-repl> lib.getLib pkgs.openssl     
«derivation /nix/store/plq8ixzschp4njfz95l0pvghx859y6qk-openssl-3.0.7.drv»

[jtojnar]

Oh, and output derivation is not a thing either. Closest is probably a “derivation output” but that is not a special thing. Really, you get the same store derivation either way – see the following pure Nix expressions (no Nixpkgs):

nix-repl> foo = (derivation { name = "foo"; outputs = ["out" "dummy"]; builder = "something"; system = builtins.currentSystem; })

nix-repl> foo
«derivation /nix/store/9h8ldpf7qihnk4fyzj6jfbl4gpsr3k9i-foo.drv»

nix-repl> foo.out
«derivation /nix/store/9h8ldpf7qihnk4fyzj6jfbl4gpsr3k9i-foo.drv»

nix-repl> foo.dummy
«derivation /nix/store/9h8ldpf7qihnk4fyzj6jfbl4gpsr3k9i-foo.drv»

The store derivation contains all outputs:

$ nix derivation show /nix/store/9h8ldpf7qihnk4fyzj6jfbl4gpsr3k9i-foo.drv
{
  "/nix/store/9h8ldpf7qihnk4fyzj6jfbl4gpsr3k9i-foo.drv": {
    "args": [],
    "builder": "something",
    "env": {
      "builder": "something",
      "dummy": "/nix/store/ssv0b9s9w3zw4br6zhghww6smiw2ghjh-foo-dummy",
      "name": "foo",
      "out": "/nix/store/fsmr038gnky9bv7z5byyss2hf6iha2q7-foo",
      "outputs": "out dummy",
      "system": "x86_64-linux"
    },
    "inputDrvs": {},
    "inputSrcs": [],
    "name": "foo",
    "outputs": {
      "dummy": {
        "path": "/nix/store/ssv0b9s9w3zw4br6zhghww6smiw2ghjh-foo-dummy"
      },
      "out": {
        "path": "/nix/store/fsmr038gnky9bv7z5byyss2hf6iha2q7-foo"
      }
    },
    "system": "x86_64-linux"
  }
}

In Nix, the derivation function will actually (in addition to producing a store derivation) return an attribute set. And it will add some extra attributes that make it special:

nix-repl> builtins.attrNames foo
[ "all" "builder" "drvAttrs" "drvPath" "dummy" "name" "out" "outPath" "outputName" "outputs" "system" "type" ]

nix-repl> {type = "derivation";}
«derivation ???»

Notably, the derivation function adds outPath attribute, which determines how an attribute set is turned into string:

nix-repl> foo.outPath
"/nix/store/fsmr038gnky9bv7z5byyss2hf6iha2q7-foo"

And also one attribute per output, that will contain a similar attribute set with outPath and outputName attributes changed:

nix-repl> foo == foo.out
true

nix-repl> foo.dummy.outPath
"/nix/store/ssv0b9s9w3zw4br6zhghww6smiw2ghjh-foo-dummy"

nix-repl> foo.dummy.outputName
"dummy"

[gabyx]

Ah, thats why the confusion..., so foo.dummy is a derivation, correct?. So whats the term for it? So dummy can be described as the attribute set of the output dummy of package foo , aka the output derivation :-). but if its not a thing, then lets call it what? derivation output (I am a non-native speaker), so really unsure if thats clearer. Maybe one should just document that pkg.${name} is returned if it exists which is a what?.

I am confused now what type pkgs.${name} really is, if its an attribute set, why does nix repl return <<...>> (e.g. a derivation).

[gabyx]

Also pkgs.openssl.bin.bin.bin.bin.bin.bin.bin exists which kind of shows that its self referencing as you stated... kind of confusing....

[gabyx]

So pkgs.openssl.bin and pkgs.openssl.man are stored at two different locations, pkgs.openssl.bin == pkgs.openssl.man is false.

[infinisil]

Since very recently Nix now calls this a "package" or "package attribute set": https://nixos.org/manual/nix/stable/glossary.html#package

But I'm not a fan of it because it confuses it with Nixpkgs notion of a package

[lolbinarycat]

note that while pkgs.openssl.bin.drvPath == pkgs.openssl.doc.drvPath, pkgs.openssl.bin.outPath != pkgs.openssl.doc.outPath.

this is because a single derivation can build multiple outputs.

and if i'm not mistaken, the nix definition of a package is based off of the nixpkgs idea of a package.

[lolbinarycat]

I'm not convinced this is actually a documentation issue.

i'm curious if everything is would still build correctly if lib.attrsets.getOutput returned pkg.outPath instead of just pkg, as it seems like that was the original intent, and it went unnoticed due to string interpolation coercing via outPath anyways.