doc/glossary: Define package and package attribute set

[roberth]

A small step towards #6507

I believe this incomplete definition is one that can be agreed on. It would be nice to define more, but considering that the issue also proposes changes to the design, I believe we should hold off on those.

As for the wording, we're dealing with some very general and vague terms, that have to be treated with exactly the right amount of vagueness to be effective.

I start out with a fairly abstract definition of package.

1. to establish a baseline so we know what we're talking about
2. so that we can go in and clarify that we have an extra, Nix-specific definition.

"Software" is notoriously ill-defined, so it makes a great qualifier for package, which we don't really want to pin down either, because that would just get us lost in discussion.
We can come back to this after we've done 6057 and a few years in a desert cave.

Then comes the "package attribute set" definition. I can already hear Valentin say "That's not even Nix's responsibility!" and on some days I might even agree.
However, in our current reality, we have nix-env, nix-build and nix profile, which query the outputName attribute - among others - which just don't exist in the derivation.

For those who can't believe what they're reading:

$ nix-build --expr 'with import ./. {}; bind // {outputName = "lib";}' --no-out-link
this path will be fetched (1.16 MiB download, 3.72 MiB unpacked):
  /nix/store/rfk6klfx3z972gavxlw6iypnj6j806ma-bind-9.18.21-lib
copying path '/nix/store/rfk6klfx3z972gavxlw6iypnj6j806ma-bind-9.18.21-lib' from 'https://cache.nixos.org'...
/nix/store/rfk6klfx3z972gavxlw6iypnj6j806ma-bind-9.18.21-lib

and let me tell you that bind is not a library.

So anyway, that's also proof of why calling this a "derivation attrset" would be wrong, despite the type attribute.

Motivation

Make our use of language more efficient by agreeing on what's what.

Be more productive together.

Context

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[fricklerhandwerk]

I can live with that.

Thanks for constructively addressing open issues.

[infinisil]

Not a fan of this because now there's two definitions of packages:

• The thing Nix calls packages as established here
• The thing Nixpkgs calls packages, which additionally has things like pname, version, meta, passthru, and most importantly follows the unwritten conventions of the output directory structure (like binaries in $out/bin or $bin), which is what makes packages installable alongside other packages

[fricklerhandwerk]

@infinisil while I'm the first to be skeptical of such a definition, I don't think it contradicts the Nixpkgs definition: which attributes are added is not specified, and neither is the directory structure. The phrasing is broad enough to be applicable.

[infinisil]

One concept is a superset of the other, but it's still two separate concepts. I wouldn't be surprised if this leads to ambiguities.

In fact, the reason I'm mentioning this at all is because in NixOS/nix.dev#887 you yourself had to explicitly specify which "Package" you're talking about:

A package is a loosely defined concept that refers to both a collection of files and other data, or a Nix expression representing such a collection before it comes into being.

Packages in Nixpkgs have conventional, mostly standardised structure, allowing them to be discovered in searches and composed in environments alongside other packages.

In just these two sentences you introduce people to these two concepts now called the same.

[fricklerhandwerk]

I don't see the contradiction. Packages in Nixpkgs just specify the Nix package concept further, no? I even added a TODO to link to the Nix manual for a first stab at disambiguation.