Describe the problem

Goals

• make outputs defined in the Nix language the source of truth, instead of derivation outputs
  • necessary for effective use of RFC 92 Computed Derivations.
  • allow even non-RFC-92 packages to reduce the build closure by splitting outputs such as doc into a separate derivation
• document what Nix expects from a package
  • define the interface between Nix and Nixpkgs
  • have a definition of "package"

Currently, packages and derivations are often the same thing, but the lack of a definition and distinction between the two can not continue since RFC 92 (computed derivations, outputOf) and the conflation has unnecessarily made the concept of a multi-derivation package ill-formed / "unthinkable".

Nix doesn't really have a notion of "package". The term is only mentioned in a few places in the code, and only defined in the context of buildenv (ie legacy nix-env). This only related to the usage of derivations in a profile, and therefore does not conflict with a definition of "package".

Nixpkgs on the other hand is all about packages, but it does not define precisely what a package is.

I propose the following definition:

A package is an attribute set with the following attributes:

• outputs: list of strings
• ${output} for each output in outputs: store path string
• name: string
• version: string
• meta: attribute set with specific optional(?) attributes
• tests: optional attrset tree of derivations and/or packages
• devShell: see Allow to get rid of nix develop "shell" logic #7501

Notably absent from the definition of a package:

• drvPath: this is an implementation detail. A package consumer really only cares about outputs, which don't need to be provided by a single derivation. Derivation path(s) can be recovered from the outputs.
• overrideAttrs, buildInputs: attributes related to the construction of a derivation. These are implementation details
• passthru: not related to the construction of a derivation, but an implementation detail for setting package attrs as opposed to derivation attrs. This attribute owes its entire existence to overrideAttrs. Without overrideAttrs, // is sufficient to set package attributes.
• all: not used by Nix itself, rarely used in Nixpkgs (regex: (?<!platforms)(?<!lib)(?<!builtins)[.]all; still mostly false positives. Only one clear usage, which has a TODO on it)

Steps To Reproduce

1. Define a package where one output comes from a different derivation. You may want to do this to keep derivation dependencies to a minimum (e.g. doc autoconf: build offline html documentation nixpkgs#172103 where it would be more desirable for the non-doc outputs not to depend on texinfo).
2. Be confused about what drvPath should be.
3. Install the package and note that the output from the non-drvPath output wasn't included.

Expected behavior

Nix represents packages by its outputs and metadata, not the drvPath implementation detail.

nix-env --version output

2.8. Or 2.x really. I would appreciate a major version increase for the (subtle) change in behavior.

Additional context

I came across this problem again in Nixpkgs today and figured I had to share my thoughts. I guess I should turn it into an RFC? I can do that later if y'all agree that we need something like this.

There's also NixOS/nixpkgs#172008 which is really a different problem, but depends on this issue, as this issue defines the interface for what current and future Nixpkgs' must implement.

I can't change the bug label on this issue. It's really a design issue rather than a bug, so another label would be more fitting. Can I have more permissions on this repo?