Documentation: pkgs.path

[olafklingt]

Problem

pkgs.path is not in the nixpkgs manual

Proposal

It should be documented but where?

Checklist

• checked latest Nixpkgs manual (source) and latest NixOS manual (source)
• checked open documentation issues for possible duplicates
• checked open documentation pull requests for possible solutions

Priorities

Add a 👍 reaction to issues you find important.

[roberth]

It refers to a source tree similar to the Nixpkgs repo, but the details are not obvious and may be subject to change, especially for the flake, because the following behavior is bad, and it's unclear to me how Nix's own behavior may change or perhaps improve this.

nix-repl> legacyPackages.x86_64-linux.path
/nix/store/rqg5d8bp8sngmhbd523dx148f8w5lfry-source

nix-repl> "${legacyPackages.x86_64-linux.path}"
"/nix/store/575lkkq24zhi5rsha0mypzdwx07039vf-rqg5d8bp8sngmhbd523dx148f8w5lfry-source"

[infinisil]

@roberth NixOS/nix#9428

[olafklingt]

My question is primarily where it should be documented.
If path should not be used what is the better alternative to path functionality? And is it documented?

[infinisil]

I think we should have a new section between "Build helpers" and "Development of Nixpkgs". It could be titled "Other attributes" and be a reference listing of all non-package, non-build-helper attributes.

[roberth]

Yes, where's the reference documentation for "pkgs"?
Here's another few

• AAAASomeThingsFailToEvaluate
• lib
• callPackage
• pkgs
• pkgsStatic
• pkgsCross
• _type (not so much a typical attribute, but a nominal type for "pkgs")

Currently the documentation does not answer the question: what is in Nixpkgs ("pkgs") besides actual packages?

Worryingly, the manual doesn't tell us Nixpkgs is a function, and it awkwardly dances around the term pkgs, just like I felt I had to do just now.

[olafklingt]

Nixpkgs is a function

Usually nix files in nixpkgs contain functions. Am I right? Are there exceptions, counter examples?

[roberth]

lib/default.nix is a counterexample, although could be considered in nixpkgs but outside Nixpkgs.
Many things in Nixpkgs need context that's not in the file, and only do "one" thing, unlike lib, so indeed most files in Nixpkgs are functions, but it doesn't follow from this that Nixpkgs would have to be a function. In fact, in the context of flakes, you can totally get away with Nixpkgs being attrsets, because you have e.g. nixpkgs.legacyPackages.x86_64-linux.pythonPackages.flask.

The fact that it's a function isn't very interesting by itself, especially if you might have guessed it. To me it's just necessary lead-up to talking about arguments and the return value "pkgs". It gives a bit of structure.