e3e57b8f18
We need this stuff to be available in lib so make-derivation.nix can access it to construct the Meson cross file. This has a couple of other advantages: - It makes Rust less special. Now figuring out what Rust calls a platform is the same as figuring out what Linux or QEMU call it. - We can unify the schema used to define Rust targets, and the schema used to access those values later. Just like you can set "config" or "system" in a platform definition, and then access those same keys on the elaborated platform, you can now set "rustcTarget" in your crossSystem, and then access "stdenv.hostPlatform.rustcTarget" in your code. "rustcTarget", "rustcTargetSpec", "cargoShortTarget", and "cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because these are not exposed to code by the compiler, and are not standardized. The arch/os/etc. variables are all named to match the forms in the Rust target spec JSON. The new rust.target-family only takes a list, since we don't need to worry about backwards compatibility when that name is used. The old APIs are all still functional with no warning for now, so that it's possible for external code to use a single API on both 23.05 and 23.11. We can introduce the warnings once 23.05 is EOL, and make them hard errors when 23.11 is EOL. |
||
---|---|---|
.. | ||
fileset | ||
path | ||
systems | ||
tests | ||
ascii-table.nix | ||
asserts.nix | ||
attrsets.nix | ||
cli.nix | ||
customisation.nix | ||
debug.nix | ||
default.nix | ||
deprecated.nix | ||
derivations.nix | ||
fetchers.nix | ||
filesystem.nix | ||
fixed-points.nix | ||
flake.nix | ||
generators.nix | ||
gvariant.nix | ||
kernel.nix | ||
licenses.nix | ||
lists.nix | ||
meta.nix | ||
minver.nix | ||
modules.nix | ||
options.nix | ||
README.md | ||
source-types.nix | ||
sources.nix | ||
strings-with-deps.nix | ||
strings.nix | ||
trivial.nix | ||
types.nix | ||
versions.nix | ||
zip-int-bits.nix |
Nixpkgs lib
This directory contains the implementation, documentation and tests for the Nixpkgs lib
library.
Overview
The evaluation entry point for lib
is default.nix
.
This file evaluates to an attribute set containing two separate kinds of attributes:
-
Sub-libraries: Attribute sets grouping together similar functionality. Each sub-library is defined in a separate file usually matching its attribute name.
Example:
lib.lists
is a sub-library containing list-related functionality such aslib.lists.take
andlib.lists.imap0
. These are defined in the filelists.nix
. -
Aliases: Attributes that point to an attribute of the same name in some sub-library.
Example:
lib.take
is an alias forlib.lists.take
.
Most files in this directory are definitions of sub-libraries, but there are a few others:
minver.nix
: A string of the minimum version of Nix that is required to evaluate Nixpkgs.tests
: Tests, see Running testsrelease.nix
: A derivation aggregating all testsmisc.nix
: Evaluation unit tests for most sub-libraries*.sh
: Bash scripts that run tests for specific sub-libraries- All other files in this directory exist to support the tests
systems
: Thelib.systems
sub-library, structured into a directory instead of a file due to its complexitypath
: Thelib.path
sub-library, which includes tests as well as a document describing the design goals oflib.path
- All other files in this directory are sub-libraries
Module system
The module system spans multiple sub-libraries:
modules.nix
:lib.modules
for the core functions and anything not relating to option definitionsoptions.nix
:lib.options
for anything relating to option definitionstypes.nix
:lib.types
for module system types
Reference documentation
Reference documentation for library functions is written above each function as a multi-line comment. These comments are processed using nixdoc and rendered in the Nixpkgs manual. The nixdoc README describes the comment format.
See the chapter on contributing to the Nixpkgs manual for how to build the manual.
Running tests
All library tests can be run by building the derivation in tests/release.nix
:
nix-build tests/release.nix
Some commands for quicker iteration over parts of the test suite are also available:
# Run all evaluation unit tests in tests/misc.nix
# if the resulting list is empty, all tests passed
nix-instantiate --eval --strict tests/misc.nix
# Run the module system tests
tests/modules.sh
# Run the lib.sources tests
tests/sources.sh
# Run the lib.filesystem tests
tests/filesystem.sh
# Run the lib.path property tests
path/tests/prop.sh
# Run the lib.fileset tests
fileset/tests.sh