nrabulinski/lix
0
0
Fork 0
forked from lix-project/lix
Code Pull requests Activity

Fix the pages in the manual for Lix

Browse source 
This doesn't comprehensively fix everything outdated in the manual, or
make the manual greatly better, but it does note down where at least
jade noticed it was wrong, and it does fix all the instances of
referencing Nix to conform to the style guide to the best of our
ability.

A lot of things have been commented out for being wrong, and there are
three types of FIXME introduced:

- FIXME(Lix): generically Lix needs to fix it
- FIXME(Qyriad): re lix-project/lix#215
- FIXME(meson): docs got outdated by meson changes and need rewriting

I did fix a bunch of it that I could, but there could certainly be
mistakes and this is definitely just an incremental improvement.

Fixes: lix-project/lix#266
Change-Id: I5993c4603d7f026a887089fce77db08394362135
This commit is contained in:
jade 2024-05-05 15:32:20 -07:00 committed by Nikodem Rabuliński
parent 36f305f6d6
commit 62d02f62a5
Signed by: nrabulinski
SSH key fingerprint: SHA256:AZZVyfKStaCo8sbJB+3Rr/CRrlym1oEgw7vMnynJeR8
51 changed files with 393 additions and 253 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/manual/book.toml
View file

@ -1,5 +1,5 @@
[book] [book]
title = "Nix Reference Manual" title = "Lix Reference Manual"
[build] [build]
create-missing = false create-missing = false
@ -7,8 +7,10 @@ create-missing = false
[output.html] [output.html]
additional-css = ["custom.css"] additional-css = ["custom.css"]
additional-js = ["redirects.js"] additional-js = ["redirects.js"]
edit-url-template = "https://github.com/NixOS/nix/tree/master/doc/manual/{path}" # Using our GitHub mirror enables easier typo fixes since there is no easy way
git-repository-url = "https://github.com/NixOS/nix" # to just submit a Gerrit CL by the web for trivial stuff.
edit-url-template = "https://github.com/lix-project/lix/tree/main/doc/manual/{path}"
git-repository-url = "https://git.lix.systems/lix-project/lix"
# Handles replacing @docroot@ with a path to ./src relative to that markdown file, # Handles replacing @docroot@ with a path to ./src relative to that markdown file,
# {{#include handlebars}}, and the @generated@ syntax used within these. it mostly # {{#include handlebars}}, and the @generated@ syntax used within these. it mostly

4
doc/manual/rl-next/enter-debugger-more-reliably-in-let-and-calls.md
View file

@ -18,8 +18,8 @@ in
b b
``` ```
Nix would correctly enter the debugger at `builtins.break a`, but if you asked Lix would correctly enter the debugger at `builtins.break a`, but if you asked
it to `:continue`, it would skip over the `builtins.break "hello"` expression it to `:continue`, it would skip over the `builtins.break "hello"` expression
entirely. entirely.
Now, Nix will correctly enter the debugger at both breakpoints. Now, Lix will correctly enter the debugger at both breakpoints.

2
doc/manual/rl-next/eval-system.md
View file

@ -6,7 +6,7 @@ prs: 4093
Add a new `eval-system` option. Add a new `eval-system` option.
Unlike `system`, it just overrides the value of `builtins.currentSystem`. Unlike `system`, it just overrides the value of `builtins.currentSystem`.
This is more useful than overriding `system`, because you can build these derivations on remote builders which can work on the given system. This is more useful than overriding `system`, because you can build these derivations on remote builders which can work on the given system.
In contrast, `system` also effects scheduling which will cause Nix to build those derivations locally even if that doesn't make sense. In contrast, `system` also effects scheduling which will cause Lix to build those derivations locally even if that doesn't make sense.
`eval-system` only takes effect if it is non-empty. `eval-system` only takes effect if it is non-empty.
If empty (the default) `system` is used as before, so there is no breakage. If empty (the default) `system` is used as before, so there is no breakage.

2
doc/manual/rl-next/nix-profile-names.md
View file

@ -6,4 +6,4 @@ cls: [978, 980]
[`nix profile`](@docroot@/command-ref/new-cli/nix3-profile.md) now uses names to refer to installed packages when running [`list`](@docroot@/command-ref/new-cli/nix3-profile-list.md), [`remove`](@docroot@/command-ref/new-cli/nix3-profile-remove.md) or [`upgrade`](@docroot@/command-ref/new-cli/nix3-profile-upgrade.md) as opposed to indices. Indices have been removed. Profile element names are generated when a package is installed and remain the same until the package is removed. [`nix profile`](@docroot@/command-ref/new-cli/nix3-profile.md) now uses names to refer to installed packages when running [`list`](@docroot@/command-ref/new-cli/nix3-profile-list.md), [`remove`](@docroot@/command-ref/new-cli/nix3-profile-remove.md) or [`upgrade`](@docroot@/command-ref/new-cli/nix3-profile-upgrade.md) as opposed to indices. Indices have been removed. Profile element names are generated when a package is installed and remain the same until the package is removed.
**Warning**: The `manifest.nix` file used to record the contents of profiles has changed. Nix will automatically upgrade profiles to the new version when you modify the profile. After that, the profile can no longer be used by older versions of Nix. **Warning**: The `manifest.nix` file used to record the contents of profiles has changed. Lix will automatically upgrade profiles to the new version when you modify the profile. After that, the profile can no longer be used by older versions of Lix.

10
doc/manual/src/SUMMARY.md
View file

@ -5,17 +5,17 @@
- [Installation](installation/installation.md) - [Installation](installation/installation.md)
- [Supported Platforms](installation/supported-platforms.md) - [Supported Platforms](installation/supported-platforms.md)
- [Installing a Binary Distribution](installation/installing-binary.md) - [Installing a Binary Distribution](installation/installing-binary.md)
- [Installing Nix from Source](installation/installing-source.md) - [Installing Lix from Source](installation/installing-source.md)
- [Prerequisites](installation/prerequisites-source.md) - [Prerequisites](installation/prerequisites-source.md)
- [Obtaining a Source Distribution](installation/obtaining-source.md) - [Obtaining a Source Distribution](installation/obtaining-source.md)
- [Building Nix from Source](installation/building-source.md) - [Building Lix from Source](installation/building-source.md)
- [Using Nix within Docker](installation/installing-docker.md) - [Using Lix within Docker](installation/installing-docker.md)
- [Security](installation/nix-security.md) - [Security](installation/nix-security.md)
- [Single-User Mode](installation/single-user.md) - [Single-User Mode](installation/single-user.md)
- [Multi-User Mode](installation/multi-user.md) - [Multi-User Mode](installation/multi-user.md)
- [Environment Variables](installation/env-variables.md) - [Environment Variables](installation/env-variables.md)
- [Upgrading Nix](installation/upgrading.md) - [Upgrading Lix](installation/upgrading.md)
- [Uninstalling Nix](installation/uninstall.md) - [Uninstalling Lix](installation/uninstall.md)
- [Package Management](package-management/package-management.md) - [Package Management](package-management/package-management.md)
- [Basic Package Management](package-management/basic-package-mgmt.md) - [Basic Package Management](package-management/basic-package-mgmt.md)
- [Profiles](package-management/profiles.md) - [Profiles](package-management/profiles.md)

4
doc/manual/src/advanced-topics/cores-vs-jobs.md
View file

@ -1,13 +1,13 @@
# Tuning Cores and Jobs # Tuning Cores and Jobs
Nix has two relevant settings with regards to how your CPU cores will Lix has two relevant settings with regards to how your CPU cores will
be utilized: `cores` and `max-jobs`. This chapter will talk about what be utilized: `cores` and `max-jobs`. This chapter will talk about what
they are, how they interact, and their configuration trade-offs. they are, how they interact, and their configuration trade-offs.
- `max-jobs`\ - `max-jobs`\
Dictates how many separate derivations will be built at the same Dictates how many separate derivations will be built at the same
time. If you set this to zero, the local machine will do no time. If you set this to zero, the local machine will do no
builds. Nix will still substitute from binary caches, and build builds. Lix will still substitute from binary caches, and build
remotely if remote builders are configured. remotely if remote builders are configured.
- `cores`\ - `cores`\

14
doc/manual/src/advanced-topics/diff-hook.md
View file

@ -1,6 +1,6 @@
# Verifying Build Reproducibility # Verifying Build Reproducibility
You can use Nix's `diff-hook` setting to compare build results. Note You can use Lix's `diff-hook` setting to compare build results. Note
that this hook is only executed if the results differ; it is not used that this hook is only executed if the results differ; it is not used
for determining if the results are the same. for determining if the results are the same.
@ -44,7 +44,7 @@ built.
Verify a path which already exists in the Nix store by passing `--check` Verify a path which already exists in the Nix store by passing `--check`
to the build command. to the build command.
If the build passes and is deterministic, Nix will exit with a status If the build passes and is deterministic, Lix will exit with a status
code of 0: code of 0:
```console ```console
@ -59,7 +59,7 @@ checking outputs of '/nix/store/z98fasz2jqy9gs0xbvdj939p27jwda38-stable.drv'...
/nix/store/yyxlzw3vqaas7wfp04g0b1xg51f2czgq-stable /nix/store/yyxlzw3vqaas7wfp04g0b1xg51f2czgq-stable
``` ```
If the build is not deterministic, Nix will exit with a status code of If the build is not deterministic, Lix will exit with a status code of
1: 1:
```console ```console
@ -75,7 +75,7 @@ error: derivation '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv' may
not be deterministic: output '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable' differs not be deterministic: output '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable' differs
``` ```
In the Nix daemon's log, we will now see: In the Lix daemon's log, we will now see:
``` ```
For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv: For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv:
@ -85,7 +85,7 @@ For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv:
> 30204 > 30204
``` ```
Using `--check` with `--keep-failed` will cause Nix to keep the second Using `--check` with `--keep-failed` will cause Lix to keep the second
build's output in a special, `.check` path: build's output in a special, `.check` path:
```console ```console
@ -98,7 +98,7 @@ from '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check'
``` ```
In particular, notice the In particular, notice the
`/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check` output. Nix `/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check` output. Lix
has copied the build results to that directory where you can examine it. has copied the build results to that directory where you can examine it.
> []{#check-dirs-are-unregistered} **Note** > []{#check-dirs-are-unregistered} **Note**
@ -114,7 +114,7 @@ has copied the build results to that directory where you can examine it.
> build was not deterministic and also a check path does not exist. > build was not deterministic and also a check path does not exist.
`--check` is only usable if the derivation has been built on the system `--check` is only usable if the derivation has been built on the system
already. If the derivation has not been built Nix will fail with the already. If the derivation has not been built Lix will fail with the
error: error:
error: some outputs of '/nix/store/hzi1h60z2qf0nb85iwnpvrai3j2w7rr6-unstable.drv' error: some outputs of '/nix/store/hzi1h60z2qf0nb85iwnpvrai3j2w7rr6-unstable.drv'

19
doc/manual/src/advanced-topics/distributed-builds.md
View file

@ -1,10 +1,10 @@
# Remote Builds # Remote Builds
Nix supports remote builds, where a local Nix installation can forward Lix supports remote builds, where a local Lix installation can forward
Nix builds to other machines. This allows multiple builds to be Nix builds to other machines. This allows multiple builds to be
performed in parallel and allows Nix to perform multi-platform builds in performed in parallel and allows Lix to perform multi-platform builds in
a semi-transparent way. For instance, if you perform a build for a a semi-transparent way. For instance, if you perform a build for a
`x86_64-darwin` on an `i686-linux` machine, Nix can automatically `x86_64-darwin` on an `i686-linux` machine, Lix can automatically
forward the build to a `x86_64-darwin` machine, if available. forward the build to a `x86_64-darwin` machine, if available.
To forward a build to a remote machine, it’s required that the remote To forward a build to a remote machine, it’s required that the remote
@ -38,12 +38,15 @@ contains Nix.
> **Warning** > **Warning**
> >
> If you are building via the Nix daemon, it is the Nix daemon user account (that is, `root`) that should have SSH access to a user (not necessarily `root`) on the remote machine. > If you are building via the Lix daemon (default on Linux and macOS), it is the Lix daemon user account (that is, `root`) that should have SSH access to a user (not necessarily `root`) on the remote machine.
>
> Furthermore, `root` needs to have the public host keys for the remote system in its `.ssh/known_hosts`.
> To add them to `known_hosts` for root, do `ssh-keyscan USER@HOST | sudo tee -a ~root/.ssh/known_hosts`.
> >
> If you can’t or don’t want to configure `root` to be able to access the remote machine, you can use a private Nix store instead by passing e.g. `--store ~/my-nix` when running a Nix command from the local machine. > If you can’t or don’t want to configure `root` to be able to access the remote machine, you can use a private Nix store instead by passing e.g. `--store ~/my-nix` when running a Nix command from the local machine.
The list of remote machines can be specified on the command line or in The list of remote machines can be specified on the command line or in
the Nix configuration file. The former is convenient for testing. For the Lix configuration file. The former is convenient for testing. For
example, the following command allows you to build a derivation for example, the following command allows you to build a derivation for
`x86_64-darwin` on a Linux machine: `x86_64-darwin` on a Linux machine:
@ -84,17 +87,17 @@ default, set it to `-`.
3. The SSH identity file to be used to log in to the remote machine. If 3. The SSH identity file to be used to log in to the remote machine. If
omitted, SSH will use its regular identities. omitted, SSH will use its regular identities.
4. The maximum number of builds that Nix will execute in parallel on 4. The maximum number of builds that Lix will execute in parallel on
the machine. Typically this should be equal to the number of CPU the machine. Typically this should be equal to the number of CPU
cores. For instance, the machine `itchy` in the example will execute cores. For instance, the machine `itchy` in the example will execute
up to 8 builds in parallel. up to 8 builds in parallel.
5. The “speed factor”, indicating the relative speed of the machine. If 5. The “speed factor”, indicating the relative speed of the machine. If
there are multiple machines of the right type, Nix will prefer the there are multiple machines of the right type, Lix will prefer the
fastest, taking load into account. fastest, taking load into account.
6. A comma-separated list of *supported features*. If a derivation has 6. A comma-separated list of *supported features*. If a derivation has
the `requiredSystemFeatures` attribute, then Nix will only perform the `requiredSystemFeatures` attribute, then Lix will only perform
the derivation on a machine that has the specified features. For the derivation on a machine that has the specified features. For
instance, the attribute instance, the attribute

6
doc/manual/src/advanced-topics/post-build-hook.md
View file

@ -8,7 +8,7 @@ simple and working example, but it is not suitable for all use cases.
The post build hook program runs after each executed build, and blocks The post build hook program runs after each executed build, and blocks
the build loop. The build loop exits if the hook program fails. the build loop. The build loop exits if the hook program fails.
Concretely, this implementation will make Nix slow or unusable when the Concretely, this implementation will make Lix slow or unusable when the
internet is slow or unreliable. internet is slow or unreliable.
A more advanced implementation might pass the store paths to a A more advanced implementation might pass the store paths to a
@ -76,7 +76,7 @@ Then make sure the hook program is executable by the `root` user:
# chmod +x /etc/nix/upload-to-cache.sh # chmod +x /etc/nix/upload-to-cache.sh
``` ```
# Updating Nix Configuration # Updating Lix Configuration
Edit `/etc/nix/nix.conf` to run our hook, by adding the following Edit `/etc/nix/nix.conf` to run our hook, by adding the following
configuration snippet at the end: configuration snippet at the end:
@ -119,7 +119,7 @@ warning: you did not specify '--add-root'; the result might be removed by the ga
# Conclusion # Conclusion
We now have a Nix installation configured to automatically sign and We now have a Lix installation configured to automatically sign and
upload every local build to a remote binary cache. upload every local build to a remote binary cache.
Before deploying this to production, be sure to consider the Before deploying this to production, be sure to consider the

6
doc/manual/src/architecture/architecture.md
View file

@ -1,7 +1,7 @@
# Architecture # Architecture
This chapter describes how Nix works. This chapter describes how Nix works.
It should help users understand why Nix behaves as it does, and it should help developers understand how to modify Nix and how to write similar tools. It should help users understand why Lix behaves as it does, and it should help developers understand how to modify Lix and how to write similar tools.
## Overview ## Overview
@ -21,8 +21,8 @@ The following [concept map] shows its main components (rectangles), the objects
| passed to | passed to
| | | |
+----------|-------------------|--------------------------------+ +----------|-------------------|--------------------------------+
| Nix | V | | Nix impl.| V |
| | +-------------------------+ | | (Lix) | +-------------------------+ |
| | | commmand line interface |------. | | | | commmand line interface |------. |
| | +-------------------------+ | | | | +-------------------------+ | |
| | | | | | | | | |

4
doc/manual/src/architecture/file-system-object.md
View file

@ -1,6 +1,6 @@
# File System Object # File System Object
Nix uses a simplified model of the file system, which consists of file system objects. Nix implementations use a simplified model of the file system, which consists of file system objects.
Every file system object is one of the following: Every file system object is one of the following:
- File - File
@ -15,7 +15,7 @@ Every file system object is one of the following:
- [Symbolic link](https://en.m.wikipedia.org/wiki/Symbolic_link) - [Symbolic link](https://en.m.wikipedia.org/wiki/Symbolic_link)
An arbitrary string. An arbitrary string.
Nix does not assign any semantics to symbolic links. Nix implementations do not assign any semantics to symbolic links.
File system objects and their children form a tree. File system objects and their children form a tree.
A bare file or symlink can be a root file system object. A bare file or symlink can be a root file system object.

2
doc/manual/src/command-ref/command-ref.md
View file

@ -1,2 +1,2 @@
This section lists commands and options that you can use when you work This section lists commands and options that you can use when you work
with Nix. with Lix.

6
doc/manual/src/command-ref/conf-file.md
View file

@ -1,14 +1,14 @@
# Name # Name
`nix.conf` - Nix configuration file `nix.conf` - Lix configuration file
# Description # Description
Nix supports a variety of configuration settings, which are read from configuration files or taken as command line flags. Lix supports a variety of configuration settings, which are read from configuration files or taken as command line flags.
## Configuration file ## Configuration file
By default Nix reads settings from the following places, in that order: By default Lix reads settings from the following places, in that order:
1. The system-wide configuration file `sysconfdir/nix/nix.conf` (i.e. `/etc/nix/nix.conf` on most systems), or `$NIX_CONF_DIR/nix.conf` if [`NIX_CONF_DIR`](./env-common.md#env-NIX_CONF_DIR) is set. 1. The system-wide configuration file `sysconfdir/nix/nix.conf` (i.e. `/etc/nix/nix.conf` on most systems), or `$NIX_CONF_DIR/nix.conf` if [`NIX_CONF_DIR`](./env-common.md#env-NIX_CONF_DIR) is set.

30
doc/manual/src/command-ref/env-common.md
View file

@ -1,6 +1,6 @@
# Common Environment Variables # Common Environment Variables
Most Nix commands interpret the following environment variables: Most commands in Lix interpret the following environment variables:
- <span id="env-IN_NIX_SHELL">[`IN_NIX_SHELL`](#env-IN_NIX_SHELL)</span>\ - <span id="env-IN_NIX_SHELL">[`IN_NIX_SHELL`](#env-IN_NIX_SHELL)</span>\
Indicator that tells if the current environment was set up by Indicator that tells if the current environment was set up by
@ -13,7 +13,7 @@ Most Nix commands interpret the following environment variables:
e.g. `/home/eelco/Dev:/etc/nixos`. It can be extended using the e.g. `/home/eelco/Dev:/etc/nixos`. It can be extended using the
[`-I` option](@docroot@/command-ref/opt-common.md#opt-I). [`-I` option](@docroot@/command-ref/opt-common.md#opt-I).
If `NIX_PATH` is not set at all, Nix will fall back to the following list in [impure](@docroot@/command-ref/conf-file.md#conf-pure-eval) and [unrestricted](@docroot@/command-ref/conf-file.md#conf-restrict-eval) evaluation mode: If `NIX_PATH` is not set at all, Lix will fall back to the following list in [impure](@docroot@/command-ref/conf-file.md#conf-pure-eval) and [unrestricted](@docroot@/command-ref/conf-file.md#conf-restrict-eval) evaluation mode:
1. `$HOME/.nix-defexpr/channels` 1. `$HOME/.nix-defexpr/channels`
2. `nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs` 2. `nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixpkgs`
@ -50,28 +50,28 @@ Most Nix commands interpret the following environment variables:
Overrides the location of the Nix store (default `prefix/store`). Overrides the location of the Nix store (default `prefix/store`).
- <span id="env-NIX_DATA_DIR">[`NIX_DATA_DIR`](#env-NIX_DATA_DIR)</span>\ - <span id="env-NIX_DATA_DIR">[`NIX_DATA_DIR`](#env-NIX_DATA_DIR)</span>\
Overrides the location of the Nix static data directory (default Overrides the location of the Lix static data directory (default
`prefix/share`). `prefix/share`).
- <span id="env-NIX_LOG_DIR">[`NIX_LOG_DIR`](#env-NIX_LOG_DIR)</span>\ - <span id="env-NIX_LOG_DIR">[`NIX_LOG_DIR`](#env-NIX_LOG_DIR)</span>\
Overrides the location of the Nix log directory (default Overrides the location of the Lix log directory (default
`prefix/var/log/nix`). `prefix/var/log/nix`).
- <span id="env-NIX_STATE_DIR">[`NIX_STATE_DIR`](#env-NIX_STATE_DIR)</span>\ - <span id="env-NIX_STATE_DIR">[`NIX_STATE_DIR`](#env-NIX_STATE_DIR)</span>\
Overrides the location of the Nix state directory (default Overrides the location of the Lix state directory (default
`prefix/var/nix`). `prefix/var/nix`).
- <span id="env-NIX_CONF_DIR">[`NIX_CONF_DIR`](#env-NIX_CONF_DIR)</span>\ - <span id="env-NIX_CONF_DIR">[`NIX_CONF_DIR`](#env-NIX_CONF_DIR)</span>\
Overrides the location of the system Nix configuration directory Overrides the location of the system Lix configuration directory
(default `prefix/etc/nix`). (default `prefix/etc/nix`).
- <span id="env-NIX_CONFIG">[`NIX_CONFIG`](#env-NIX_CONFIG)</span>\ - <span id="env-NIX_CONFIG">[`NIX_CONFIG`](#env-NIX_CONFIG)</span>\
Applies settings from Nix configuration from the environment. Applies settings from Lix configuration from the environment.
The content is treated as if it was read from a Nix configuration file. The content is treated as if it was read from a Lix configuration file.
Settings are separated by the newline character. Settings are separated by the newline character.
- <span id="env-NIX_USER_CONF_FILES">[`NIX_USER_CONF_FILES`](#env-NIX_USER_CONF_FILES)</span>\ - <span id="env-NIX_USER_CONF_FILES">[`NIX_USER_CONF_FILES`](#env-NIX_USER_CONF_FILES)</span>\
Overrides the location of the Nix user configuration files to load from. Overrides the location of the Lix user configuration files to load from.
The default are the locations according to the [XDG Base Directory Specification]. The default are the locations according to the [XDG Base Directory Specification].
See the [XDG Base Directories](#xdg-base-directories) sub-section for details. See the [XDG Base Directories](#xdg-base-directories) sub-section for details.
@ -84,19 +84,19 @@ Most Nix commands interpret the following environment variables:
substantial amounts of disk space. The default is `/tmp`. substantial amounts of disk space. The default is `/tmp`.
- <span id="env-NIX_REMOTE">[`NIX_REMOTE`](#env-NIX_REMOTE)</span>\ - <span id="env-NIX_REMOTE">[`NIX_REMOTE`](#env-NIX_REMOTE)</span>\
This variable should be set to `daemon` if you want to use the Nix This variable should be set to `daemon` if you want to use the Lix
daemon to execute Nix operations. This is necessary in [multi-user daemon to execute Nix operations. This is necessary in [multi-user
Nix installations](@docroot@/installation/multi-user.md). If the Nix Nix installations](@docroot@/installation/multi-user.md). If the Lix
daemon's Unix socket is at some non-standard path, this variable daemon's Unix socket is at some non-standard path, this variable
should be set to `unix://path/to/socket`. Otherwise, it should be should be set to `unix://path/to/socket`. Otherwise, it should be
left unset. left unset.
- <span id="env-NIX_SHOW_STATS">[`NIX_SHOW_STATS`](#env-NIX_SHOW_STATS)</span>\ - <span id="env-NIX_SHOW_STATS">[`NIX_SHOW_STATS`](#env-NIX_SHOW_STATS)</span>\
If set to `1`, Nix will print some evaluation statistics, such as If set to `1`, Lix will print some evaluation statistics, such as
the number of values allocated. the number of values allocated.
- <span id="env-NIX_COUNT_CALLS">[`NIX_COUNT_CALLS`](#env-NIX_COUNT_CALLS)</span>\ - <span id="env-NIX_COUNT_CALLS">[`NIX_COUNT_CALLS`](#env-NIX_COUNT_CALLS)</span>\
If set to `1`, Nix will print how often functions were called during If set to `1`, Lix will print how often functions were called during
Nix expression evaluation. This is useful for profiling your Nix Nix expression evaluation. This is useful for profiling your Nix
expressions. expressions.
@ -108,9 +108,9 @@ Most Nix commands interpret the following environment variables:
## XDG Base Directories ## XDG Base Directories
Nix follows the [XDG Base Directory Specification]. Lix follows the [XDG Base Directory Specification].
For backwards compatibility, Nix commands will follow the standard only when [`use-xdg-base-directories`] is enabled. For backwards compatibility, commands in Lix will follow the standard only when [`use-xdg-base-directories`] is enabled.
[New Nix commands](@docroot@/command-ref/new-cli/nix.md) (experimental) conform to the standard by default. [New Nix commands](@docroot@/command-ref/new-cli/nix.md) (experimental) conform to the standard by default.
The following environment variables are used to determine locations of various state and configuration files: The following environment variables are used to determine locations of various state and configuration files:

2
doc/manual/src/command-ref/files.md
View file

@ -1,4 +1,4 @@
# Files # Files
This section lists configuration files that you can use when you work This section lists configuration files that you can use when you work
with Nix. with Lix.

2
doc/manual/src/command-ref/files/profiles.md
View file

@ -21,7 +21,7 @@ lrwxrwxrwx 1 alice users 51 Oct 29 13:20 /home/alice/.local/state/nix/profiles/p
lrwxrwxrwx 1 alice users 51 Nov 25 14:35 /home/alice/.local/state/nix/profiles/profile-7-link -> /nix/store/mp0x6xnsg0b8qhswy6riqvimai4gm677-profile lrwxrwxrwx 1 alice users 51 Nov 25 14:35 /home/alice/.local/state/nix/profiles/profile-7-link -> /nix/store/mp0x6xnsg0b8qhswy6riqvimai4gm677-profile
``` ```
Each of these symlinks is a root for the Nix garbage collector. Each of these symlinks is a root for the Lix garbage collector.
The contents of the store path corresponding to each version of the The contents of the store path corresponding to each version of the
profile is a tree of symlinks to the files of the installed packages, profile is a tree of symlinks to the files of the installed packages,

2
doc/manual/src/command-ref/main-commands.md
View file

@ -1,4 +1,4 @@
# Main Commands # Main Commands
This section lists commands and options that you can use when you work This section lists commands and options that you can use when you work
with Nix. with Lix.

4
doc/manual/src/command-ref/nix-collect-garbage.md
View file

@ -37,7 +37,9 @@ Instead, it looks in a few locations, and acts on all profiles it finds there:
> Not stable; subject to change > Not stable; subject to change
> >
> Do not rely on this functionality; it just exists for migration purposes and is may change in the future. > Do not rely on this functionality; it just exists for migration purposes and is may change in the future.
> These deprecated paths remain a private implementation detail of Nix. > These deprecated paths remain a private implementation detail of Lix.
<!-- FIXME(Qyriad): this is inconsistent with https://git.lix.systems/lix-project/lix/issues/215, needs updating when that happens -->
`$NIX_STATE_DIR/profiles` and `$NIX_STATE_DIR/profiles/per-user`. `$NIX_STATE_DIR/profiles` and `$NIX_STATE_DIR/profiles/per-user`.

4
doc/manual/src/command-ref/nix-daemon.md
View file

@ -1,6 +1,6 @@
# Name # Name
`nix-daemon` - Nix multi-user support daemon `nix-daemon` - Lix multi-user support daemon
# Synopsis # Synopsis
@ -8,6 +8,6 @@
# Description # Description
The Nix daemon is necessary in multi-user Nix installations. It runs The Lix daemon is necessary in multi-user Lix installations. It runs
build tasks and other operations on the Nix store on behalf of build tasks and other operations on the Nix store on behalf of
unprivileged users. unprivileged users.

36
doc/manual/src/command-ref/opt-common.md
View file

@ -1,6 +1,6 @@
# Common Options # Common Options
Most Nix commands accept the following command-line options: Most commands in Lix accept the following command-line options:
- <span id="opt-help">[`--help`](#opt-help)</span> - <span id="opt-help">[`--help`](#opt-help)</span>
@ -8,12 +8,12 @@ Most Nix commands accept the following command-line options:
- <span id="opt-version">[`--version`](#opt-version)</span> - <span id="opt-version">[`--version`](#opt-version)</span>
Prints out the Nix version number on standard output and exits. Prints out the Lix version number on standard output and exits.
- <span id="opt-verbose">[`--verbose`](#opt-verbose)</span> / `-v` - <span id="opt-verbose">[`--verbose`](#opt-verbose)</span> / `-v`
Increases the level of verbosity of diagnostic messages printed on standard error. Increases the level of verbosity of diagnostic messages printed on standard error.
For each Nix operation, the information printed on standard output is well-defined; For each Lix operation, the information printed on standard output is well-defined;
any diagnostic information is printed on standard error, never on standard output. any diagnostic information is printed on standard error, never on standard output.
This option may be specified repeatedly. This option may be specified repeatedly.
@ -21,11 +21,11 @@ Most Nix commands accept the following command-line options:
- `0` “Errors only” - `0` “Errors only”
Only print messages explaining why the Nix invocation failed. Only print messages explaining why the Lix invocation failed.
- `1` “Informational” - `1` “Informational”
Print *useful* messages about what Nix is doing. Print *useful* messages about what Lix is doing.
This is the default. This is the default.
- `2` “Talkative” - `2` “Talkative”
@ -80,13 +80,13 @@ Most Nix commands accept the following command-line options:
- <span id="opt-no-build-output">[`--no-build-output`](#opt-no-build-output)</span> / `-Q` - <span id="opt-no-build-output">[`--no-build-output`](#opt-no-build-output)</span> / `-Q`
By default, output written by builders to standard output and standard error is echoed to the Nix command's standard error. By default, output written by builders to standard output and standard error is echoed to the Lix command's standard error.
This option suppresses this behaviour. This option suppresses this behaviour.
Note that the builder's standard output and error are always written to a log file in `prefix/nix/var/log/nix`. Note that the builder's standard output and error are always written to a log file in `prefix/nix/var/log/nix`.
- <span id="opt-max-jobs">[`--max-jobs`](#opt-max-jobs)</span> / `-j` *number* - <span id="opt-max-jobs">[`--max-jobs`](#opt-max-jobs)</span> / `-j` *number*
Sets the maximum number of build jobs that Nix will perform in parallel to the specified number. Sets the maximum number of build jobs that Lix will perform in parallel to the specified number.
Specify `auto` to use the number of CPUs in the system. Specify `auto` to use the number of CPUs in the system.
The default is specified by the `max-jobs` configuration setting, which itself defaults to `1`. The default is specified by the `max-jobs` configuration setting, which itself defaults to `1`.
A higher value is useful on SMP systems or to exploit I/O latency. A higher value is useful on SMP systems or to exploit I/O latency.
@ -116,8 +116,8 @@ Most Nix commands accept the following command-line options:
- <span id="opt-keep-going">[`--keep-going`](#opt-keep-going)</span> / `-k` - <span id="opt-keep-going">[`--keep-going`](#opt-keep-going)</span> / `-k`
Keep going in case of failed builds, to the greatest extent possible. Keep going in case of failed builds, to the greatest extent possible.
That is, if building an input of some derivation fails, Nix will still build the other inputs, but not the derivation itself. That is, if building an input of some derivation fails, Lix will still build the other inputs, but not the derivation itself.
Without this option, Nix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds). Without this option, Lix stops if any build fails (except for builds of substitutes), possibly killing builds in progress (in case of parallel or distributed builds).
- <span id="opt-keep-failed">[`--keep-failed`](#opt-keep-failed)</span> / `-K` - <span id="opt-keep-failed">[`--keep-failed`](#opt-keep-failed)</span> / `-K`
@ -126,18 +126,24 @@ Most Nix commands accept the following command-line options:
- <span id="opt-fallback">[`--fallback`](#opt-fallback)</span> - <span id="opt-fallback">[`--fallback`](#opt-fallback)</span>
Whenever Nix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation. Whenever Lix attempts to build a derivation for which substitutes are known for each output path, but realising the output paths through the substitutes fails, fall back on building the derivation.
The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository. The most common scenario in which this is useful is when we have registered substitutes in order to perform binary distribution from, say, a network repository.
If the repository is down, the realisation of the derivation will fail. If the repository is down, the realisation of the derivation will fail.
When this option is specified, Nix will build the derivation instead. When this option is specified, Lix will build the derivation instead.
Thus, installation from binaries falls back on installation from source. Thus, installation from binaries falls back on installation from source.
This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources). This option is not the default since it is generally not desirable for a transient failure in obtaining the substitutes to lead to a full build from source (with the related consumption of resources).
- <span id="opt-readonly-mode">[`--readonly-mode`](#opt-readonly-mode)</span> - <span id="opt-readonly-mode">[`--readonly-mode`](#opt-readonly-mode)</span>
When this option is used, no attempt is made to open the Nix database. When this option is used, no attempt is made to open the Lix database.
Most Nix operations do need database access, so those operations will fail. Most Lix operations do need database access, so those operations will fail.
<div class="warning">
FIXME(Lix): sometimes you want `--store dummy` instead, because this option sometimes doesn't work. Document why this is.
</div>
- <span id="opt-arg">[`--arg`](#opt-arg)</span> *name* *value* - <span id="opt-arg">[`--arg`](#opt-arg)</span> *name* *value*
@ -195,8 +201,8 @@ Most Nix commands accept the following command-line options:
- <span id="opt-option">[`--option`](#opt-option)</span> *name* *value* - <span id="opt-option">[`--option`](#opt-option)</span> *name* *value*
Set the Nix configuration option *name* to *value*. Set the Lix configuration option *name* to *value*.
This overrides settings in the Nix configuration file (see nix.conf5). This overrides settings in the Lix configuration file (see nix.conf(5)).
- <span id="opt-repair">[`--repair`](#opt-repair)</span> - <span id="opt-repair">[`--repair`](#opt-repair)</span>

2
doc/manual/src/command-ref/utilities.md
View file

@ -1,3 +1,3 @@
# Utilities # Utilities
This section lists utilities that you can use when you work with Nix. This section lists utilities that you can use when you work with Lix.

12
doc/manual/src/contributing/cli-guideline.md
View file

@ -11,12 +11,12 @@ follow to ensure a consistent and approachable user experience.
`nix` command provides a single entry to a number of sub-commands that help `nix` command provides a single entry to a number of sub-commands that help
**developers and system administrators** in the life-cycle of a software **developers and system administrators** in the life-cycle of a software
project. We particularly need to pay special attention to help and assist new project. We particularly need to pay special attention to help and assist new
users of Nix. users of Lix.
# Naming the `COMMANDS` # Naming the `COMMANDS`
Words matter. Naming is an important part of the usability. Users will be Words matter. Naming is an important part of the usability. Users will be
interacting with Nix on a regular basis so we should **name things for ease of interacting with Lix on a regular basis so we should **name things for ease of
understanding**. understanding**.
We recommend following the [Principle of Least We recommend following the [Principle of Least
@ -184,7 +184,7 @@ Initializing Nix project at `/path/to/here`.
### Next steps ### Next steps
It can be invaluable to newcomers to show what a possible next steps and what It can be invaluable to newcomers to show what a possible next steps and what
is the usual development workflow with Nix. For example: is the usual development workflow with Lix. For example:
```shell ```shell
@ -317,7 +317,7 @@ compromise between being terse and being verbose, between showing help to
beginners and annoying advance users. For this it is important that we know beginners and annoying advance users. For this it is important that we know
what are the priorities. what are the priorities.
Nix command line should be first and foremost written with beginners in mind. Lix command line should be first and foremost written with beginners in mind.
But users won't stay beginners for long and what was once useful might quickly But users won't stay beginners for long and what was once useful might quickly
become annoying. There is no golden rule that we can give in this guideline become annoying. There is no golden rule that we can give in this guideline
that would make it easier how to draw a line and find best compromise. that would make it easier how to draw a line and find best compromise.
@ -331,7 +331,7 @@ certain `OPTIONS`, etc…)
## Follow best practices ## Follow best practices
Needless to say we Nix must be a good citizen and follow best practices in Needless to say we Lix must be a good citizen and follow best practices in
command line. command line.
In short: **STDOUT is for output, STDERR is for (human) messaging.** In short: **STDOUT is for output, STDERR is for (human) messaging.**
@ -462,7 +462,7 @@ However, simply converting everything to records is not enough, because the orde
{ "outputs": { "bin": {}, "out": {} } } { "outputs": { "bin": {}, "out": {} } }
``` ```
The first item is the default output. Deriving this information from the outputs ordering is not great, but this is how Nix currently happens to work. The first item is the default output. Deriving this information from the outputs ordering is not great, but this is how Lix currently happens to work.
While it is possible for a JSON parser to preserve the order of fields, we can not rely on this capability to be present in all JSON libraries. While it is possible for a JSON parser to preserve the order of fields, we can not rely on this capability to be present in all JSON libraries.
This representation is extensible and preserves the ordering: This representation is extensible and preserves the ordering:

11
doc/manual/src/contributing/experimental-features.md
View file

@ -1,4 +1,11 @@
This section describes the notion of *experimental features*, and how it fits into the big picture of the development of Nix. This section describes the notion of *experimental features*, and how it fits into the big picture of the development of Lix.
<div class="warning">
This section has not been updated for Lix *development practices* and should not be considered authoritative with respect to those; see the Lix wiki for more up-to-date information as it gets written <https://wiki.lix.systems/books/lix-contributors>. The technical content on this page is correct.
</div>
# What are experimental features? # What are experimental features?
@ -12,7 +19,7 @@ This was a source of confusion and controversy.
# When should a new feature be marked experimental? # When should a new feature be marked experimental?
A change in the Nix codebase should be guarded by an experimental feature flag if it is considered likely to be reverted or adapted in a backwards-incompatible manner after gathering more experience with it in practice. A change in the Lix codebase should be guarded by an experimental feature flag if it is considered likely to be reverted or adapted in a backwards-incompatible manner after gathering more experience with it in practice.
Examples: Examples:

21
doc/manual/src/contributing/hacking.md
View file

@ -1,6 +1,6 @@
# Hacking # Hacking
This section provides some notes on how to hack on Nix. To get the latest version of Lix from Forgejo: This section provides some notes on how to hack on Lix. To get the latest version of Lix from Forgejo:
```console ```console
$ git clone https://git.lix.systems/lix-project/lix $ git clone https://git.lix.systems/lix-project/lix
@ -120,13 +120,13 @@ $ meson introspect
## Building Lix outside of development shells ## Building Lix outside of development shells
To build a release version of Nix for the current operating system and CPU architecture: To build a release version of Lix for the current operating system and CPU architecture:
```console ```console
$ nix build $ nix build
``` ```
You can also build Nix for one of the [supported platforms](#platforms). You can also build Lix for one of the [supported platforms](#platforms).
> **Note** > **Note**
> >
@ -135,7 +135,7 @@ You can also build Nix for one of the [supported platforms](#platforms).
## Platforms ## Platforms
Nix can be built for various platforms, as specified in [`flake.nix`]: Lix can be built for various platforms, as specified in [`flake.nix`]:
[`flake.nix`]: https://github.com/nixos/nix/blob/master/flake.nix [`flake.nix`]: https://github.com/nixos/nix/blob/master/flake.nix
@ -147,7 +147,7 @@ Nix can be built for various platforms, as specified in [`flake.nix`]:
- `armv6l-linux` - `armv6l-linux`
- `armv7l-linux` - `armv7l-linux`
In order to build Nix for a different platform than the one you're currently In order to build Lix for a different platform than the one you're currently
on, you need a way for your current Nix installation to build code for that on, you need a way for your current Nix installation to build code for that
platform. Common solutions include [remote builders] and [binary format emulation] platform. Common solutions include [remote builders] and [binary format emulation]
(only supported on NixOS). (only supported on NixOS).
@ -196,7 +196,7 @@ Lix uses a string with the following format to identify the *system type* or *pl
<cpu>-<os>[-<abi>] <cpu>-<os>[-<abi>]
``` ```
It is set when Nix is compiled for the given system, and determined by [Meson's `host_machine.cpu_family()` and `host_machine.system()` values](https://mesonbuild.com/Reference-manual_builtin_host_machine.html). It is set when Lix is compiled for the given system, and determined by [Meson's `host_machine.cpu_family()` and `host_machine.system()` values](https://mesonbuild.com/Reference-manual_builtin_host_machine.html).
For historic reasons and backward-compatibility, some CPU and OS identifiers are translated from the GNU Autotools naming convention in [`meson.build`](https://git.lix.systems/lix-project/lix/blob/main/meson.build) as follows: For historic reasons and backward-compatibility, some CPU and OS identifiers are translated from the GNU Autotools naming convention in [`meson.build`](https://git.lix.systems/lix-project/lix/blob/main/meson.build) as follows:
@ -212,7 +212,7 @@ For historic reasons and backward-compatibility, some CPU and OS identifiers are
## Compilation environments ## Compilation environments
Nix can be compiled using multiple environments: Lix can be compiled using multiple environments:
- `stdenv`: default; - `stdenv`: default;
- `gccStdenv`: force the use of `gcc` compiler; - `gccStdenv`: force the use of `gcc` compiler;
@ -325,8 +325,13 @@ Here's what a complete entry looks like. The file name is not incorporated in th
``` ```
--- ---
synopsis: Basically a title synopsis: Basically a title
issues: 1234 # 1234 or gh#1234 will refer to CppNix GitHub, fj#1234 will refer to a Lix forgejo issue.
issues: [1234, fj#1234]
# Use this *only* if there is a CppNix pull request associated with this change
prs: 1238 prs: 1238
# List of Lix Gerrit changelist numbers; if there is an associated Lix GitHub
# PR, just put in the Gerrit CL number.
cls: [123]
--- ---
Here's one or more paragraphs that describe the change. Here's one or more paragraphs that describe the change.

47
doc/manual/src/contributing/testing.md
View file

@ -32,7 +32,9 @@ The unit tests are defined using the [googletest] and [rapidcheck] frameworks.
> … > …
> ``` > ```
The unit tests for each Nix library (`libnixexpr`, `libnixstore`, etc..) live inside a directory `src/${library_shortname}/tests` within the directory for the library (`src/${library_shortname}`). <!-- FIXME(Lix): this might get renamed to liblixexpr, etc? -->
The unit tests for each Lix library (`libnixexpr`, `libnixstore`, etc..) live inside a directory `src/${library_shortname}/tests` within the directory for the library (`src/${library_shortname}`).
The data is in `unit-test-data`, with one subdir per library, with the same name as where the code goes. The data is in `unit-test-data`, with one subdir per library, with the same name as where the code goes.
For example, `libnixstore` code is in `src/libstore`, and its test data is in `unit-test-data/libstore`. For example, `libnixstore` code is in `src/libstore`, and its test data is in `unit-test-data/libstore`.
@ -45,8 +47,13 @@ The path to the `unit-test-data` directory is passed to the unit test executable
### Running tests ### Running tests
You can run the whole testsuite with `make check`, or the tests for a specific component with `make libfoo-tests_RUN`. You can run the whole testsuite with `just test` (see justfile for exact invocation of meson), and if you want to run just one test suite, use `just test --suite installcheck functional-init` where `installcheck` is the name of the test suite in this case and `functional-init` is the name of the test.
Finer-grained filtering is also possible using the [--gtest_filter](https://google.github.io/googletest/advanced.html#running-a-subset-of-the-tests) command-line option, or the `GTEST_FILTER` environment variable.
To get a list of tests, use `meson test -C build --list`.
For `installcheck` specifically, first run `just install` before running the test suite (this is due to meson limitations that don't let us put a dependency on installing before doing the test).
Finer-grained filtering within a test suite is also possible using the [--gtest_filter](https://google.github.io/googletest/advanced.html#running-a-subset-of-the-tests) command-line option to a test suite executable, or the `GTEST_FILTER` environment variable.
### Unit test support libraries ### Unit test support libraries
@ -85,6 +92,11 @@ Each test is a bash script.
### Running the whole test suite ### Running the whole test suite
<div class="warning">
FIXME(meson): this section is wrong for meson and commented out accordingly. See "Running Tests" above, and ask the Lix team if you need further clarification.
</div>
<!--
The whole test suite can be run with: The whole test suite can be run with:
```shell-session ```shell-session
@ -148,6 +160,8 @@ output from bar
The test script will then be traced with `set -x` and the output displayed as it happens, regardless of whether the test succeeds or fails. The test script will then be traced with `set -x` and the output displayed as it happens, regardless of whether the test succeeds or fails.
-->
### Debugging failing functional tests ### Debugging failing functional tests
When a functional test fails, it usually does so somewhere in the middle of the script. When a functional test fails, it usually does so somewhere in the middle of the script.
@ -170,6 +184,10 @@ edit it like so:
bar bar
``` ```
<div class="warning">
FIXME(meson): the command here may be incorrect for meson.
</div>
Then, running the test with `./mk/debug-test.sh` will drop you into GDB once the script reaches that point: Then, running the test with `./mk/debug-test.sh` will drop you into GDB once the script reaches that point:
```shell-session ```shell-session
@ -186,11 +204,15 @@ For example, enter `run` to start the Nix invocation.
### Characterization testing ### Characterization testing
Occasionally, Nix utilizes a technique called [Characterization Testing](https://en.wikipedia.org/wiki/Characterization_test) as part of the functional tests. Occasionally, Lix utilizes a technique called [Characterization Testing](https://en.wikipedia.org/wiki/Characterization_test) as part of the functional tests.
This technique is to include the exact output/behavior of a former version of Nix in a test in order to check that Nix continues to produce the same behavior going forward. This technique is to include the exact output/behavior of a former version of Nix in a test in order to check that Lix continues to produce the same behavior going forward.
For example, this technique is used for the language tests, to check both the printed final value if evaluation was successful, and any errors and warnings encountered. For example, this technique is used for the language tests, to check both the printed final value if evaluation was successful, and any errors and warnings encountered.
<div class="warning">
FIXME(meson): this is incorrect for meson. `_NIX_TEST_ACCEPT=1` is still valid but the test invocation needs to change.
</div>
It is frequently useful to regenerate the expected output. It is frequently useful to regenerate the expected output.
To do that, rerun the failed test(s) with `_NIX_TEST_ACCEPT=1`. To do that, rerun the failed test(s) with `_NIX_TEST_ACCEPT=1`.
For example: For example:
@ -214,14 +236,21 @@ To ensure that characterization testing doesn't make it harder to intentionally
## Integration tests ## Integration tests
The integration tests are defined in the Nix flake under the `hydraJobs.tests` attribute. The integration tests are defined in the Nix flake under the `hydraJobs.tests` attribute.
These tests include everything that needs to interact with external services or run Nix in a non-trivial distributed setup. These tests include everything that needs to interact with external services or run Lix in a non-trivial distributed setup.
Because these tests are expensive and require more than what the standard github-actions setup provides, they only run on the master branch (on <https://hydra.nixos.org/jobset/nix/master>). Because these tests are expensive and require more than what the standard github-actions setup provides, they only run on the master branch (on <https://hydra.nixos.org/jobset/nix/master>).
You can run them manually with `nix build .#hydraJobs.tests.{testName}` or `nix-build -A hydraJobs.tests.{testName}` You can run them manually with `nix build .#hydraJobs.tests.{testName}` or `nix-build -A hydraJobs.tests.{testName}`
<div class="warning">
Installer tests section is outdated and commented out, see https://git.lix.systems/lix-project/lix/issues/33
</div>
<!--
## Installer tests ## Installer tests
After a one-time setup, the Nix repository's GitHub Actions continuous integration (CI) workflow can test the installer each time you push to a branch. After a one-time setup, the Lix repository's GitHub Actions continuous integration (CI) workflow can test the installer each time you push to a branch.
Creating a Cachix cache for your installer tests and adding its authorization token to GitHub enables [two installer-specific jobs in the CI workflow](https://github.com/NixOS/nix/blob/88a45d6149c0e304f6eb2efcc2d7a4d0d569f8af/.github/workflows/ci.yml#L50-L91): Creating a Cachix cache for your installer tests and adding its authorization token to GitHub enables [two installer-specific jobs in the CI workflow](https://github.com/NixOS/nix/blob/88a45d6149c0e304f6eb2efcc2d7a4d0d569f8af/.github/workflows/ci.yml#L50-L91):
@ -261,7 +290,7 @@ After the CI run completes, you can check the output to extract the installer UR
curl -L <install_url> | sh -s -- --tarball-url-prefix https://<github-username>-nix-install-tests.cachix.org/serve curl -L <install_url> | sh -s -- --tarball-url-prefix https://<github-username>-nix-install-tests.cachix.org/serve
``` ```
<!-- #### Manually generating test installers <!~~ #### Manually generating test installers
There's obviously a manual way to do this, and it's still the only way for There's obviously a manual way to do this, and it's still the only way for
platforms that lack GA runners. platforms that lack GA runners.
@ -288,4 +317,6 @@ search/replaced in it for each new build.
The installer now supports a `--tarball-url-prefix` flag which _may_ have The installer now supports a `--tarball-url-prefix` flag which _may_ have
solved this need? solved this need?
~~>
--> -->

8
doc/manual/src/glossary.md
View file

@ -57,12 +57,12 @@
The location in the file system where store objects live. Typically The location in the file system where store objects live. Typically
`/nix/store`. `/nix/store`.
From the perspective of the location where Nix is From the perspective of the location where Lix is
invoked, the Nix store can be referred to invoked, the Nix store can be referred to
as a "_local_" or a "_remote_" one: as a "_local_" or a "_remote_" one:
+ A [local store]{#gloss-local-store} exists on the filesystem of + A [local store]{#gloss-local-store} exists on the filesystem of
the machine where Nix is invoked. You can use other the machine where Lix is invoked. You can use other
local stores by passing the `--store` flag to the local stores by passing the `--store` flag to the
`nix` command. Local stores can be used for building derivations. `nix` command. Local stores can be used for building derivations.
@ -133,7 +133,7 @@
- [substituter]{#gloss-substituter} - [substituter]{#gloss-substituter}
An additional [store]{#gloss-store} from which Nix can obtain store objects instead of building them. An additional [store]{#gloss-store} from which Lix can obtain store objects instead of building them.
Often the substituter is a [binary cache](#gloss-binary-cache), but any store can serve as substituter. Often the substituter is a [binary cache](#gloss-binary-cache), but any store can serve as substituter.
See the [`substituters` configuration option](./command-ref/conf-file.md#conf-substituters) for details. See the [`substituters` configuration option](./command-ref/conf-file.md#conf-substituters) for details.
@ -159,7 +159,7 @@
- [Nix expression]{#gloss-nix-expression} - [Nix expression]{#gloss-nix-expression}
A high-level description of software packages and compositions A high-level description of software packages and compositions
thereof. Deploying software using Nix entails writing Nix thereof. Deploying software using Lix entails writing Nix
expressions for your packages. Nix expressions are translated to expressions for your packages. Nix expressions are translated to
derivations that are stored in the Nix store. These derivations can derivations that are stored in the Nix store. These derivations can
then be built. then be built.

12
doc/manual/src/installation/building-source.md
View file

@ -1,6 +1,13 @@
# Building Nix from Source # Building Lix from Source
After cloning Nix's Git repository, issue the following commands: <div class="warning">
FIXME(meson): This section is outdated for meson and has been commented out. See https://git.lix.systems/lix-project/lix/issues/258
</div>
<!--
After cloning Lix's Git repository, issue the following commands:
```console ```console
$ autoreconf -vfi $ autoreconf -vfi
@ -29,3 +36,4 @@ Nix keeps its *store* (the place where packages are stored) in
Nix keeps state (such as its database and log files) in `/nix/var` by Nix keeps state (such as its database and log files) in `/nix/var` by
default. This can be changed using `--localstatedir=path`. default. This can be changed using `--localstatedir=path`.
-->

24
doc/manual/src/installation/env-variables.md
View file

@ -1,6 +1,6 @@
# Environment Variables # Environment Variables
To use Nix, some environment variables should be set. In particular, To use Lix, some environment variables should be set. In particular,
`PATH` should contain the directories `prefix/bin` and `PATH` should contain the directories `prefix/bin` and
`~/.nix-profile/bin`. The first directory contains the Nix tools `~/.nix-profile/bin`. The first directory contains the Nix tools
themselves, while `~/.nix-profile` is a symbolic link to the current themselves, while `~/.nix-profile` is a symbolic link to the current
@ -16,20 +16,30 @@ source prefix/etc/profile.d/nix.sh
# `NIX_SSL_CERT_FILE` # `NIX_SSL_CERT_FILE`
<div class="warning">
FIXME(Lix): This section is undoubtedly wrong due to the Lix installer being replaced. The definitely-wrong install section has been commented out.
</div>
If you need to specify a custom certificate bundle to account for an If you need to specify a custom certificate bundle to account for an
HTTPS-intercepting man in the middle proxy, you must specify the path to HTTPS-intercepting man in the middle proxy, you must specify the path to
the certificate bundle in the environment variable `NIX_SSL_CERT_FILE`. the certificate bundle in the environment variable `NIX_SSL_CERT_FILE`.
If you don't specify a `NIX_SSL_CERT_FILE` manually, Nix will install If you don't specify a `NIX_SSL_CERT_FILE` manually, Lix will install
and use its own certificate bundle. and use its own certificate bundle.
Set the environment variable and install Nix <!--
Set the environment variable and install Lix
```console ```console
$ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt $ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
$ curl -L https://nixos.org/nix/install | sh $ curl -L https://nixos.org/nix/install | sh
``` ```
-->
In the shell profile and rc files (for example, `/etc/bashrc`, In the shell profile and rc files (for example, `/etc/bashrc`,
`/etc/zshrc`), add the following line: `/etc/zshrc`), add the following line:
@ -39,10 +49,10 @@ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
> **Note** > **Note**
> >
> You must not add the export and then do the install, as the Nix > You must not add the export and then do the install, as the Lix
> installer will detect the presence of Nix configuration, and abort. > installer will detect the presence of Nix configuration, and abort.
If you use the Nix daemon, you should also add the following to If you use the Lix daemon, you should also add the following to
`/etc/nix/nix.conf`: `/etc/nix/nix.conf`:
``` ```
@ -51,11 +61,11 @@ ssl-cert-file = /etc/ssl/my-certificate-bundle.crt
## Proxy Environment Variables ## Proxy Environment Variables
The Nix installer has special handling for these proxy-related The Lix installer has special handling for these proxy-related
environment variables: `http_proxy`, `https_proxy`, `ftp_proxy`, environment variables: `http_proxy`, `https_proxy`, `ftp_proxy`,
`no_proxy`, `HTTP_PROXY`, `HTTPS_PROXY`, `FTP_PROXY`, `NO_PROXY`. `no_proxy`, `HTTP_PROXY`, `HTTPS_PROXY`, `FTP_PROXY`, `NO_PROXY`.
If any of these variables are set when running the Nix installer, then If any of these variables are set when running the Lix installer, then
the installer will create an override file at the installer will create an override file at
`/etc/systemd/system/nix-daemon.service.d/override.conf` so `nix-daemon` `/etc/systemd/system/nix-daemon.service.d/override.conf` so `nix-daemon`
will use them. will use them.

33
doc/manual/src/installation/installation.md
View file

@ -1,38 +1,15 @@
# Installation # Installation
This section describes how to install and configure Nix for first-time use. See https://lix.systems/install/ for more details.
The current recommended option on Linux and MacOS is [multi-user](#multi-user). <!--
## Multi-user FIXME(Lix): Distributions section is probably good but is definitely outdated as of this writing given nobody has packaged Lix yet (2024-05-05)
This installation offers better sharing, improved isolation, and more security
over a single user installation.
This option requires either:
* Linux running systemd, with SELinux disabled
* MacOS
```console
$ bash <(curl -L https://nixos.org/nix/install) --daemon
```
## Single-user
> Single-user is not supported on Mac.
This installation has less requirements than the multi-user install, however it
cannot offer equivalent sharing, isolation, or security.
This option is suitable for systems without systemd.
```console
$ bash <(curl -L https://nixos.org/nix/install) --no-daemon
```
## Distributions ## Distributions
The Nix community maintains installers for several distributions. The Nix community maintains installers for several distributions.
They can be found in the [`nix-community/nix-installers`](https://github.com/nix-community/nix-installers) repository. They can be found in the [`nix-community/nix-installers`](https://github.com/nix-community/nix-installers) repository.
-->

14
doc/manual/src/installation/installing-binary.md
View file

@ -1,5 +1,11 @@
# Installing a Binary Distribution # Installing a Binary Distribution
See https://lix.systems/install/ for more details.
<!--
FIXME(Lix): There are a bunch of technical details on *how* nix is installed in here that we want to keep but it would need serious rewriting.
The easiest way to install Nix is to run the following command: The easiest way to install Nix is to run the following command:
```console ```console
@ -81,7 +87,7 @@ extension. The installer will also create `/etc/profile.d/nix.sh`.
# macOS Installation # macOS Installation
[]{#sect-macos-installation-change-store-prefix}[]{#sect-macos-installation-encrypted-volume}[]{#sect-macos-installation-symlink}[]{#sect-macos-installation-recommended-notes} []{#sect-macos-installation-change-store-prefix}[]{#sect-macos-installation-encrypted-volume}[]{#sect-macos-installation-symlink}[]{#sect-macos-installation-recommended-notes}
<!-- Note: anchors above to catch permalinks to old explanations --> <!~~ Note: anchors above to catch permalinks to old explanations ~~>
We believe we have ironed out how to cleanly support the read-only root We believe we have ironed out how to cleanly support the read-only root
on modern macOS. New installs will do this automatically. on modern macOS. New installs will do this automatically.
@ -101,7 +107,7 @@ this to run the installer, but it may help if you run into trouble:
- `nobrowse`: prevent the Nix Store volume from showing up on your - `nobrowse`: prevent the Nix Store volume from showing up on your
desktop; also keeps Spotlight from spending resources to index desktop; also keeps Spotlight from spending resources to index
this volume this volume
<!-- TODO: <!~~ TODO:
- `suid`: honor setuid? surely not? ... - `suid`: honor setuid? surely not? ...
- `owners`: honor file ownership on the volume - `owners`: honor file ownership on the volume
@ -117,7 +123,7 @@ this to run the installer, but it may help if you run into trouble:
new reports from coming in. But I hesitate to celebrate because we new reports from coming in. But I hesitate to celebrate because we
haven't really named and catalogued the behavior, understood what haven't really named and catalogued the behavior, understood what
we're fixing, and validated that all 3 components are essential. we're fixing, and validated that all 3 components are essential.
--> ~~>
- if you have FileVault enabled - if you have FileVault enabled
- generate an encryption password - generate an encryption password
- put it in your system Keychain - put it in your system Keychain
@ -156,3 +162,5 @@ $ ./install
If you need to edit the multi-user installation script to use different If you need to edit the multi-user installation script to use different
group ID or a different user ID range, modify the variables set in the group ID or a different user ID range, modify the variables set in the
file named `install-multi-user`. file named `install-multi-user`.
-->

15
doc/manual/src/installation/installing-docker.md
View file

@ -1,6 +1,10 @@
# Using Nix within Docker # Using Lix within Docker
To run the latest stable release of Nix with Docker run the following command: Currently the Lix project doesn't ship docker images. However, we have the infrastructure to do it, it's just not yet been done. See https://git.lix.systems/lix-project/lix/issues/252
<!--
To run the latest stable release of Lix with Docker run the following command:
```console ```console
$ docker run -ti nixos/nix $ docker run -ti nixos/nix
@ -16,7 +20,7 @@ nix (Nix) 2.3.12
35ca4ada6e96:/# exit 35ca4ada6e96:/# exit
``` ```
# What is included in Nix's Docker image? # What is included in Lix's Docker image?
The official Docker image is created using `pkgs.dockerTools.buildLayeredImage` The official Docker image is created using `pkgs.dockerTools.buildLayeredImage`
(and not with `Dockerfile` as it is usual with Docker images). You can still (and not with `Dockerfile` as it is usual with Docker images). You can still
@ -24,7 +28,7 @@ base your custom Docker image on it as you would do with any other Docker
image. image.
The Docker image is also not based on any other image and includes minimal set The Docker image is also not based on any other image and includes minimal set
of runtime dependencies that are required to use Nix: of runtime dependencies that are required to use Lix:
- pkgs.nix - pkgs.nix
- pkgs.bashInteractive - pkgs.bashInteractive
@ -40,7 +44,7 @@ of runtime dependencies that are required to use Nix:
- pkgs.cacert.out - pkgs.cacert.out
- pkgs.findutils - pkgs.findutils
# Docker image with the latest development version of Nix # Docker image with the latest development version of Lix
To get the latest image that was built by [Hydra](https://hydra.nixos.org) run To get the latest image that was built by [Hydra](https://hydra.nixos.org) run
the following command: the following command:
@ -57,3 +61,4 @@ $ nix build ./\#hydraJobs.dockerImage.x86_64-linux
$ docker load -i ./result/image.tar.gz $ docker load -i ./result/image.tar.gz
$ docker run -ti nix:2.5pre20211105 $ docker run -ti nix:2.5pre20211105
``` ```
-->

6
doc/manual/src/installation/installing-source.md
View file

@ -1,4 +1,4 @@
# Installing Nix from Source # Installing Lix from Source
If no binary package is available or if you want to hack on Nix, you If no binary package is available or if you want to hack on Lix, you
can build Nix from its Git repository. can build Lix from its Git repository.

6
doc/manual/src/installation/nix-security.md
View file

@ -1,15 +1,15 @@
# Security # Security
Nix has two basic security models. First, it can be used in “single-user Lix has two basic security models. First, it can be used in “single-user
mode”, which is similar to what most other package management tools do: mode”, which is similar to what most other package management tools do:
there is a single user (typically root) who performs all package there is a single user (typically root) who performs all package
management operations. All other users can then use the installed management operations. All other users can then use the installed
packages, but they cannot perform package management operations packages, but they cannot perform package management operations
themselves. themselves.
Alternatively, you can configure Nix in “multi-user mode”. In this Alternatively, you can configure Lix in “multi-user mode”. In this
model, all users can perform package management operations — for model, all users can perform package management operations — for
instance, every user can install software without requiring root instance, every user can install software without requiring root
privileges. Nix ensures that this is secure. For instance, it’s not privileges. Lix ensures that this is secure. For instance, it’s not
possible for one user to overwrite a package used by another user with a possible for one user to overwrite a package used by another user with a
Trojan horse. Trojan horse.

12
doc/manual/src/installation/prerequisites-source.md
View file

@ -1,5 +1,15 @@
# Prerequisites # Prerequisites
<div class="warning">
FIXME(meson): This section is very wrong with respect to meson and we have commented it out.
We are sorry.
The most current alternative to this section is to read `package.nix` and see which things are being depended on.
</div>
<!--
- GNU Autoconf (<https://www.gnu.org/software/autoconf/>) and the - GNU Autoconf (<https://www.gnu.org/software/autoconf/>) and the
autoconf-archive macro collection autoconf-archive macro collection
(<https://www.gnu.org/software/autoconf-archive/>). These are (<https://www.gnu.org/software/autoconf-archive/>). These are
@ -76,3 +86,5 @@
RapidCheck are required, which are available at RapidCheck are required, which are available at
<https://google.github.io/googletest/> and <https://google.github.io/googletest/> and
<https://github.com/emil-e/rapidcheck> respectively. <https://github.com/emil-e/rapidcheck> respectively.
-->

10
doc/manual/src/installation/supported-platforms.md
View file

@ -1,7 +1,11 @@
# Supported Platforms # Supported Platforms
Nix is currently supported on the following platforms: Lix is currently supported on the following platforms:
- Linux (i686, x86\_64, aarch64). - Linux (i686 (tier 2), x86\_64 (tier 1), aarch64 (tier 1)).
- macOS (x86\_64, aarch64). - macOS (x86\_64 (tier 2 [(issue to make tier 1)](https://git.lix.systems/lix-project/lix/issues/269)), aarch64 (tier 1)).
Tier 2 platforms aren't checked in CI, so may break without notice; such breakage *is* however considered a bug.
We would like for them to work but they are a secondary priority.

21
doc/manual/src/installation/uninstall.md
View file

@ -1,8 +1,18 @@
# Uninstalling Nix # Uninstalling Lix
<div class="warning">
FIXME(Lix): This section is outdated and commented out due to the Lix installer being replaced such that it has an actual uninstaller.
See https://git.lix.systems/lix-project/lix-installer#uninstalling for up-to-date uninstallation instructions using the installer.
</div>
<!--
## Single User ## Single User
If you have a [single-user installation](./installing-binary.md#single-user-installation) of Nix, uninstall it by running: If you have a [single-user installation](./installing-binary.md#single-user-installation) of Lix, uninstall it by running:
```console ```console
$ rm -rf /nix $ rm -rf /nix
@ -10,7 +20,7 @@ $ rm -rf /nix
## Multi User ## Multi User
Removing a [multi-user installation](./installing-binary.md#multi-user-installation) of Nix is more involved, and depends on the operating system. Removing a [multi-user installation](./installing-binary.md#multi-user-installation) of Lix is more involved, and depends on the operating system.
### Linux ### Linux
@ -24,7 +34,7 @@ If you are on Linux with systemd:
sudo systemctl daemon-reload sudo systemctl daemon-reload
``` ```
Remove files created by Nix: Remove files created by Lix:
```console ```console
sudo rm -rf /etc/nix /etc/profile.d/nix.sh /etc/tmpfiles.d/nix-daemon.conf /nix ~root/.nix-channels ~root/.nix-defexpr ~root/.nix-profile sudo rm -rf /etc/nix /etc/profile.d/nix.sh /etc/tmpfiles.d/nix-daemon.conf /nix ~root/.nix-channels ~root/.nix-defexpr ~root/.nix-profile
@ -39,7 +49,7 @@ done
sudo groupdel nixbld sudo groupdel nixbld
``` ```
There may also be references to Nix in There may also be references to Lix in
- `/etc/bash.bashrc` - `/etc/bash.bashrc`
- `/etc/bashrc` - `/etc/bashrc`
@ -145,3 +155,4 @@ which you may remove.
> complete. macOS (Catalina+) directly controls root directories and its > complete. macOS (Catalina+) directly controls root directories and its
> read-only root will prevent you from manually deleting the empty `/nix` > read-only root will prevent you from manually deleting the empty `/nix`
> mountpoint. > mountpoint.
-->

31
doc/manual/src/installation/upgrading.md
View file

@ -1,14 +1,23 @@
# Upgrading Nix # Upgrading Lix
Multi-user Nix users on macOS can upgrade Nix by running: `sudo -i sh -c <div class="warning">
'nix-channel --update &&
nix-env --install --attr nixpkgs.nix &&
launchctl remove org.nixos.nix-daemon &&
launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist'`
Single-user installations of Nix should run this: `nix-channel --update; FIXME(Lix): does Lix forward to the installer for `nix upgrade-nix`? Should it, if present? Lix *should* restart the daemon for you [but currently doesn't (issue)](https://git.lix.systems/lix-project/lix/issues/267).
nix-env --install --attr nixpkgs.nix nixpkgs.cacert`
Multi-user Nix users on Linux should run this with sudo: `nix-channel </div>
--update; nix-env --install --attr nixpkgs.nix nixpkgs.cacert; systemctl
daemon-reload; systemctl restart nix-daemon` **For instructions to switch to Lix**, see <https://lix.systems/install>.
Lix may be upgraded by running `nix upgrade-nix` and then restarting the Nix daemon.
## Restarting daemon on Linux
`sudo systemctl daemon-reload && sudo systemctl restart nix-daemon`
## Restarting daemon on macOS
<div class="warning">
FIXME(Lix): Write instructions that, according to the [beta installation guide](https://wiki.lix.systems/link/1) do not sometimes crash macOS (?!)
</div>

43
doc/manual/src/introduction.md
View file

@ -1,12 +1,8 @@
# Introduction # Introduction
Nix is a _purely functional package manager_. This means that it Lix is an implementation of Nix, a powerful, _purely functional_ package management system.
treats packages like values in purely functional programming languages This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built.
such as Haskell — they are built by functions that don’t have Lix stores packages in the _Nix store_, usually the directory `/nix/store`, where each package has its own unique subdirectory such as
side-effects, and they never change after they have been built. Nix
stores packages in the _Nix store_, usually the directory
`/nix/store`, where each package has its own unique subdirectory such
as
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/ /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/
@ -31,7 +27,7 @@ used by other packages.
## Complete dependencies ## Complete dependencies
Nix helps you make sure that package dependency specifications are Lix helps you make sure that package dependency specifications are
complete. In general, when you’re making a package for a package complete. In general, when you’re making a package for a package
management system like RPM, you have to specify for each package what management system like RPM, you have to specify for each package what
its dependencies are, but there are no guarantees that this its dependencies are, but there are no guarantees that this
@ -40,7 +36,7 @@ package will build and work correctly on _your_ machine if you have
the dependency installed, but not on the end user's machine if it's the dependency installed, but not on the end user's machine if it's
not there. not there.
Since Nix on the other hand doesn’t install packages in “global” Since Lix on the other hand doesn’t install packages in “global”
locations like `/usr/bin` but in package-specific directories, the locations like `/usr/bin` but in package-specific directories, the
risk of incomplete dependencies is greatly reduced. This is because risk of incomplete dependencies is greatly reduced. This is because
tools such as compilers don’t search in per-packages directories such tools such as compilers don’t search in per-packages directories such
@ -54,13 +50,11 @@ This sounds risky, but it works extremely well.
## Multi-user support ## Multi-user support
Nix has multi-user support. This means that non-privileged users can Lix has multi-user support.
securely install software. Each user can have a different _profile_, This means that non-privileged users can securely install software, and it is considered a bug if users can trample on each other.
a set of packages in the Nix store that appear in the user’s `PATH`. Each user can have a different _profile_, a set of packages in the Nix store that appear in the user’s `PATH`.
If a user installs a package that another user has already installed If a user installs a package that another user has already installed previously, the package won’t be built or downloaded a second time.
previously, the package won’t be built or downloaded a second time. At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user.
At the same time, it is not possible for one user to inject a Trojan
horse into a package that might be used by another user.
## Atomic upgrades and rollbacks ## Atomic upgrades and rollbacks
@ -106,7 +100,7 @@ Packages are built from _Nix expressions_, which is a simple
functional language. A Nix expression describes everything that goes functional language. A Nix expression describes everything that goes
into a package build task (a “derivation”): other packages, sources, into a package build task (a “derivation”): other packages, sources,
the build script, environment variables for the build script, etc. the build script, environment variables for the build script, etc.
Nix tries very hard to ensure that Nix expressions are Lix tries very hard to ensure that Nix expressions are
_deterministic_: building a Nix expression twice should yield the same _deterministic_: building a Nix expression twice should yield the same
result. result.
@ -130,22 +124,21 @@ also all its dependencies (all the way up to the C library and the
compiler) would have to be built, at least if they are not already in the compiler) would have to be built, at least if they are not already in the
Nix store. This is a _source deployment model_. For most users, Nix store. This is a _source deployment model_. For most users,
building from source is not very pleasant as it takes far too long. building from source is not very pleasant as it takes far too long.
However, Nix can automatically skip building from source and instead However, Lix can automatically skip building from source and instead
use a _binary cache_, a web server that provides pre-built use a _binary cache_, a web server that provides pre-built
binaries. For instance, when asked to build binaries. For instance, when asked to build
`/nix/store/b6gvzjyb2pg0…-firefox-33.1` from source, Nix would first `/nix/store/b6gvzjyb2pg0…-firefox-33.1` from source, Lix would first
check if the file `https://cache.nixos.org/b6gvzjyb2pg0….narinfo` check if the file `https://cache.nixos.org/b6gvzjyb2pg0….narinfo`
exists, and if so, fetch the pre-built binary referenced from there; exists, and if so, fetch the pre-built binary referenced from there;
otherwise, it would fall back to building from source. otherwise, it would fall back to building from source.
## Nix Packages collection ## Nix Packages collection
We provide a large set of Nix expressions containing hundreds of We provide a large set of Nix expressions containing tens of thousands of existing Unix packages, the _Nix Packages collection_ (Nixpkgs).
existing Unix packages, the _Nix Packages collection_ (Nixpkgs).
## Managing build environments ## Managing build environments
Nix is extremely useful for developers as it makes it easy to Lix is extremely useful for developers as it makes it easy to
automatically set up the build environment for a package. Given a Nix automatically set up the build environment for a package. Given a Nix
expression that describes the dependencies of your package, the expression that describes the dependencies of your package, the
command `nix-shell` will build or download those dependencies if command `nix-shell` will build or download those dependencies if
@ -174,11 +167,11 @@ the package:
## Portability ## Portability
Nix runs on Linux and macOS. Lix runs on Linux and macOS.
## NixOS ## NixOS
NixOS is a Linux distribution based on Nix. It uses Nix not just for NixOS is a Linux distribution based on Nix technology. It uses Nix not just for
package management but also to manage the system configuration (e.g., package management but also to manage the system configuration (e.g.,
to build configuration files in `/etc`). This means, among other to build configuration files in `/etc`). This means, among other
things, that it is easy to roll back the entire configuration of the things, that it is easy to roll back the entire configuration of the
@ -188,6 +181,6 @@ homepage](https://nixos.org/).
## License ## License
Nix is released under the terms of the [GNU LGPLv2.1 or (at your Lix is released under the terms of the [GNU LGPLv2.1 or (at your
option) any later option) any later
version](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html). version](http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html).

10
doc/manual/src/language/advanced-attributes.md
View file

@ -116,7 +116,7 @@ Derivations can declare some infrequently used optional attributes.
These attributes declare that the derivation is a so-called These attributes declare that the derivation is a so-called
*fixed-output derivation*, which means that a cryptographic hash of *fixed-output derivation*, which means that a cryptographic hash of
the output is already known in advance. When the build of a the output is already known in advance. When the build of a
fixed-output derivation finishes, Nix computes the cryptographic fixed-output derivation finishes, Lix computes the cryptographic
hash of the output and compares it to the hash declared with these hash of the output and compares it to the hash declared with these
attributes. If there is a mismatch, the build fails. attributes. If there is a mismatch, the build fails.
@ -241,7 +241,7 @@ Derivations can declare some infrequently used optional attributes.
then when the builder runs, the environment variable `bigPath` then when the builder runs, the environment variable `bigPath`
will contain the absolute path to a temporary file containing `a will contain the absolute path to a temporary file containing `a
very long string`. That is, for any attribute *x* listed in very long string`. That is, for any attribute *x* listed in
`passAsFile`, Nix will pass an environment variable `xPath` `passAsFile`, Lix will pass an environment variable `xPath`
holding the path of the file containing the value of attribute holding the path of the file containing the value of attribute
*x*. This is useful when you need to pass large strings to a *x*. This is useful when you need to pass large strings to a
builder, since most operating systems impose a limit on the size builder, since most operating systems impose a limit on the size
@ -256,13 +256,13 @@ Derivations can declare some infrequently used optional attributes.
the cost of building locally. the cost of building locally.
- [`allowSubstitutes`]{#adv-attr-allowSubstitutes}\ - [`allowSubstitutes`]{#adv-attr-allowSubstitutes}\
If this attribute is set to `false`, then Nix will always build this If this attribute is set to `false`, then Lix will always build this
derivation; it will not try to substitute its outputs. This is derivation; it will not try to substitute its outputs. This is
useful for very trivial derivations (such as `writeText` in Nixpkgs) useful for very trivial derivations (such as `writeText` in Nixpkgs)
that are cheaper to build than to substitute from a binary cache. that are cheaper to build than to substitute from a binary cache.
You may disable the effects of this attibute by enabling the You may disable the effects of this attibute by enabling the
`always-allow-substitutes` configuration option in Nix. `always-allow-substitutes` configuration option in Lix.
> **Note** > **Note**
> >
@ -284,7 +284,7 @@ Derivations can declare some infrequently used optional attributes.
[`outputChecks`](#adv-attr-outputChecks) for example. [`outputChecks`](#adv-attr-outputChecks) for example.
As a convenience to Bash builders, As a convenience to Bash builders,
Nix writes a script that initialises shell variables Lix writes a script that initialises shell variables
corresponding to all attributes that are representable in Bash. The corresponding to all attributes that are representable in Bash. The
environment variable `NIX_ATTRS_SH_FILE` points to the exact environment variable `NIX_ATTRS_SH_FILE` points to the exact
location of the script, both in a build and a location of the script, both in a build and a

12
doc/manual/src/language/derivations.md
View file

@ -61,7 +61,7 @@ the attributes of which specify the inputs of the build.
outputs = [ "lib" "headers" "doc" ]; outputs = [ "lib" "headers" "doc" ];
``` ```
This will cause Nix to pass environment variables `lib`, `headers` This will cause Lix to pass environment variables `lib`, `headers`
and `doc` to the builder containing the intended store paths of each and `doc` to the builder containing the intended store paths of each
output. The builder would typically do something like output. The builder would typically do something like
@ -137,7 +137,7 @@ The builder is executed as follows:
it’s `out`.) it’s `out`.)
- If an output path already exists, it is removed. Also, locks are - If an output path already exists, it is removed. Also, locks are
acquired to prevent multiple Nix instances from performing the same acquired to prevent multiple Lix instances from performing the same
build at the same time. build at the same time.
- A log of the combined standard output and error is written to - A log of the combined standard output and error is written to
@ -150,17 +150,17 @@ The builder is executed as follows:
- The temporary directory is removed (unless the `-K` option was - The temporary directory is removed (unless the `-K` option was
specified). specified).
- If the build was successful, Nix scans each output path for - If the build was successful, Lix scans each output path for
references to input paths by looking for the hash parts of the input references to input paths by looking for the hash parts of the input
paths. Since these are potential runtime dependencies, Nix registers paths. Since these are potential runtime dependencies, Lix registers
them as dependencies of the output paths. them as dependencies of the output paths.
- After the build, Nix sets the last-modified timestamp on all files - After the build, Lix sets the last-modified timestamp on all files
in the build result to 1 (00:00:01 1/1/1970 UTC), sets the group to in the build result to 1 (00:00:01 1/1/1970 UTC), sets the group to
the default group, and sets the mode of the file to 0444 or 0555 the default group, and sets the mode of the file to 0444 or 0555
(i.e., read-only, with execute permission enabled if the file was (i.e., read-only, with execute permission enabled if the file was
originally executable). Note that possible `setuid` and `setgid` originally executable). Note that possible `setuid` and `setgid`
bits are cleared. Setuid and setgid programs are not currently bits are cleared. Setuid and setgid programs are not currently
supported by Nix. This is because the Nix archives used in supported by Lix. This is because the Lix archives used in
deployment have no concept of ownership information, and because it deployment have no concept of ownership information, and because it
makes the build result dependent on the user performing the build. makes the build result dependent on the user performing the build.

31
doc/manual/src/package-management/basic-package-mgmt.md
View file

@ -1,11 +1,20 @@
# Basic Package Management # Basic Package Management
<div class="warning">
FIXME(Lix): This section does not document the most common modern practices in terms of avoiding channels, pinning, declarative software installation (see flakey-profile or home-manager or NixOS), or using flakes, etc.
It is, however, likely correct at a technical level.
For more information on modern practices, see the [resources](https://lix.systems/resources) page on the Lix site.
</div>
The main command for package management is The main command for package management is
[`nix-env`](../command-ref/nix-env.md). You can use it to install, [`nix-env`](../command-ref/nix-env.md). You can use it to install,
upgrade, and erase packages, and to query what packages are installed upgrade, and erase packages, and to query what packages are installed
or are available for installation. or are available for installation.
In Nix, different users can have different “views” on the set of In Nix systems, different users can have different “views” on the set of
installed applications. That is, there might be lots of applications installed applications. That is, there might be lots of applications
present on the system (possibly in many different versions), but users present on the system (possibly in many different versions), but users
can have a specific selection of those active — where “active” just can have a specific selection of those active — where “active” just
@ -14,12 +23,12 @@ on the set of installed applications is called a *user environment*,
which is just a directory tree consisting of symlinks to the files of which is just a directory tree consisting of symlinks to the files of
the active applications. the active applications.
Components are installed from a set of *Nix expressions* that tell Nix Components are installed from a set of *Nix expressions* that tell Lix
how to build those packages, including, if necessary, their how to build those packages, including, if necessary, their
dependencies. There is a collection of Nix expressions called the dependencies. There is a very large collection of Nix expressions called the
Nixpkgs package collection that contains packages ranging from basic Nixpkgs package collection that contains packages ranging from basic
development stuff such as GCC and Glibc, to end-user applications like development stuff such as GCC and Glibc, to end-user applications like
Mozilla Firefox. (Nix is however not tied to the Nixpkgs package Mozilla Firefox. (Lix is however not tied to the Nixpkgs package
collection; you could write your own Nix expressions based on Nixpkgs, collection; you could write your own Nix expressions based on Nixpkgs,
or completely new ones.) or completely new ones.)
@ -28,7 +37,7 @@ You can manually download the latest version of Nixpkgs from
convenient to use the Nixpkgs [*channel*](../command-ref/nix-channel.md), since it makes convenient to use the Nixpkgs [*channel*](../command-ref/nix-channel.md), since it makes
it easy to stay up to date with new versions of Nixpkgs. Nixpkgs is it easy to stay up to date with new versions of Nixpkgs. Nixpkgs is
automatically added to your list of “subscribed” channels when you automatically added to your list of “subscribed” channels when you
install Nix. If this is not the case for some reason, you can add it install Lix. If this is not the case for some reason, you can add it
as follows: as follows:
```console ```console
@ -107,7 +116,7 @@ present on your system (in which case installing it into your user
environment would be a very quick operation). The last one (`S`) environment would be a very quick operation). The last one (`S`)
indicates whether there is a so-called *substitute* for the package, indicates whether there is a so-called *substitute* for the package,
which is Nix’s mechanism for doing binary deployment. It just means that which is Nix’s mechanism for doing binary deployment. It just means that
Nix knows that it can fetch a pre-built package from somewhere Lix knows that it can fetch a pre-built package from somewhere
(typically a network server) instead of building it locally. (typically a network server) instead of building it locally.
You can install a package using `nix-env --install --attr `. For instance, You can install a package using `nix-env --install --attr `. For instance,
@ -121,12 +130,12 @@ will install the package called `subversion` from `nixpkgs` channel (which is, o
> **Note** > **Note**
> >
> When you ask Nix to install a package, it will first try to get it in > When you ask Lix to install a package, it will first try to get it in
> pre-compiled form from a *binary cache*. By default, Nix will use the > pre-compiled form from a *binary cache*. By default, Lix will use the
> binary cache <https://cache.nixos.org>; it contains binaries for most > binary cache <https://cache.nixos.org>; it contains binaries for most
> packages in Nixpkgs. Only if no binary is available in the binary > packages in Nixpkgs. Only if no binary is available in the binary
> cache, Nix will build the package from source. So if `nix-env > cache, Lix will build the package from source. So if `nix-env
> -iA nixpkgs.subversion` results in Nix building stuff from source, then either > -iA nixpkgs.subversion` results in Lix building stuff from source, then either
> the package is not built for your platform by the Nixpkgs build > the package is not built for your platform by the Nixpkgs build
> servers, or your version of Nixpkgs is too old or too new. For > servers, or your version of Nixpkgs is too old or too new. For
> instance, if you have a very recent checkout of Nixpkgs, then the > instance, if you have a very recent checkout of Nixpkgs, then the
@ -147,7 +156,7 @@ $ nix-env --uninstall subversion
``` ```
Upgrading to a new version is just as easy. If you have a new release of Upgrading to a new version is just as easy. If you have a new release of
Nix Packages, you can do: nixpkgs, you can do:
```console ```console
$ nix-env --upgrade --attr nixpkgs.subversion $ nix-env --upgrade --attr nixpkgs.subversion

24
doc/manual/src/package-management/binary-cache-substituter.md
View file

@ -1,8 +1,21 @@
# Serving a Nix store via HTTP # Serving a Nix store via HTTP
<div class="warning">
FIXME(Lix): This section documents outdated practices.
In particular, the Lix developers would *not* recommend using `nix-serve` as it is relatively-unmaintained Perl.
The Lix developers would recommend instead using an s3 based cache (which is what https://cache.nixos.org is), and if it is desired to self-host it, use something like [garage](https://garagehq.deuxfleurs.fr/).
See the following projects:
- [attic](https://github.com/zhaofengli/attic) - multi-tenant cache for larger deployments, using s3 as a backend.
- [harmonia](https://github.com/nix-community/harmonia) - closer to a drop in replacement for use cases served by nix-serve
</div>
You can easily share the Nix store of a machine via HTTP. This allows You can easily share the Nix store of a machine via HTTP. This allows
other machines to fetch store paths from that machine to speed up other machines to fetch store paths from that machine to speed up
installations. It uses the same *binary cache* mechanism that Nix installations. It uses the same *binary cache* mechanism that Lix
usually uses to fetch pre-built binaries from <https://cache.nixos.org>. usually uses to fetch pre-built binaries from <https://cache.nixos.org>.
The daemon that handles binary cache requests via HTTP, `nix-serve`, is The daemon that handles binary cache requests via HTTP, `nix-serve`, is
@ -31,20 +44,19 @@ which should print something like:
WantMassQuery: 1 WantMassQuery: 1
Priority: 30 Priority: 30
On the client side, you can tell Nix to use your binary cache using On the client side, you can tell Lix to use your binary cache using `--substituters` (assuming you are a trusted user, see `trusted-users` in nix.conf), e.g.:
`--substituters`, e.g.:
```console ```console
$ nix-env --install --attr nixpkgs.firefox --substituters http://avalon:8080/ $ nix-env --install --attr nixpkgs.firefox --substituters http://avalon:8080/
``` ```
The option `substituters` tells Nix to use this binary cache in The option `substituters` tells Lix to use this binary cache in
addition to your default caches, such as <https://cache.nixos.org>. addition to your default caches, such as <https://cache.nixos.org>.
Thus, for any path in the closure of Firefox, Nix will first check if Thus, for any path in the closure of Firefox, Lix will first check if
the path is available on the server `avalon` or another binary caches. the path is available on the server `avalon` or another binary caches.
If not, it will fall back to building from source. If not, it will fall back to building from source.
You can also tell Nix to always use your binary cache by adding a line You can also tell Lix to always use your binary cache by adding a line
to the `nix.conf` configuration file like this: to the `nix.conf` configuration file like this:
substituters = http://avalon:8080/ https://cache.nixos.org/ substituters = http://avalon:8080/ https://cache.nixos.org/

2
doc/manual/src/package-management/garbage-collection.md
View file

@ -6,7 +6,7 @@ is to create a new user environment that no longer contains symlinks to
the “deleted” packages. the “deleted” packages.
Of course, since disk space is not infinite, unused packages should be Of course, since disk space is not infinite, unused packages should be
removed at some point. You can do this by running the Nix garbage removed at some point. You can do this by running the Lix garbage
collector. It will remove from the Nix store any package not used collector. It will remove from the Nix store any package not used
(directly or indirectly) by any generation of any profile. (directly or indirectly) by any generation of any profile.

2
doc/manual/src/package-management/package-management.md
View file

@ -1,4 +1,4 @@
This chapter discusses how to do package management with Nix, i.e., This chapter discusses how to do package management with Lix, i.e.,
how to obtain, install, upgrade, and erase packages. This is the how to obtain, install, upgrade, and erase packages. This is the
“user’s” perspective of the Nix system — people who want to *create* “user’s” perspective of the Nix system — people who want to *create*
packages should consult the chapter on the [Nix language](../language/index.md). packages should consult the chapter on the [Nix language](../language/index.md).

29
doc/manual/src/package-management/s3-substituter.md
View file

@ -1,17 +1,28 @@
# Serving a Nix store via S3 # Serving a Nix store via S3
Nix has [built-in support](@docroot@/command-ref/new-cli/nix3-help-stores.md#s3-binary-cache-store) Lix has [built-in support](@docroot@/command-ref/new-cli/nix3-help-stores.md#s3-binary-cache-store)
for storing and fetching store paths from for storing and fetching store paths from Amazon S3 and S3-compatible services.
Amazon S3 and S3-compatible services. This uses the same *binary*
cache mechanism that Nix usually uses to fetch prebuilt binaries from <div class="warning">
FIXME(Lix): document the correct setup to fetch from a s3 cache via HTTP rather than just through `s3://` (which works, but forces you to remain s3-like on the client side)
</div>
<!--
FIXME(Lix): no it doesn't! cache.nixos.org is just http!
This uses the same *binary*
cache mechanism that Lix usually uses to fetch prebuilt binaries from
[cache.nixos.org](https://cache.nixos.org/). [cache.nixos.org](https://cache.nixos.org/).
-->
In this example we will use the bucket named `example-nix-cache`. In this example we will use the bucket named `example-nix-cache`.
## Anonymous Reads to your S3-compatible binary cache ## Anonymous Reads to your S3-compatible binary cache
If your binary cache is publicly accessible and does not require If your binary cache is publicly accessible and does not require
authentication, the simplest and easiest way to use Nix with your S3 authentication, the simplest and easiest way to use Lix with your S3
compatible binary cache is to use the HTTP URL for that cache. compatible binary cache is to use the HTTP URL for that cache.
For AWS S3 the binary cache URL for example bucket will be exactly For AWS S3 the binary cache URL for example bucket will be exactly
@ -48,11 +59,11 @@ Your bucket will need the following bucket policy:
For AWS S3 the binary cache URL for example bucket will be exactly For AWS S3 the binary cache URL for example bucket will be exactly
<s3://example-nix-cache>. <s3://example-nix-cache>.
Nix will use the [default credential provider Lix will use the [default credential provider
chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html) chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html)
for authenticating requests to Amazon S3. for authenticating requests to Amazon S3.
Nix supports authenticated reads from Amazon S3 and S3 compatible binary Lix supports authenticated reads from Amazon S3 and S3 compatible binary
caches. caches.
Your bucket will need a bucket policy allowing the desired users to Your bucket will need a bucket policy allowing the desired users to
@ -63,11 +74,11 @@ updated to have a restricted `Principal` to support this.
## Authenticated Writes to your S3-compatible binary cache ## Authenticated Writes to your S3-compatible binary cache
Nix support fully supports writing to Amazon S3 and S3 compatible Lix support fully supports writing to Amazon S3 and S3 compatible
buckets. The binary cache URL for our example bucket will be buckets. The binary cache URL for our example bucket will be
<s3://example-nix-cache>. <s3://example-nix-cache>.
Nix will use the [default credential provider Lix will use the [default credential provider
chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html) chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html)
for authenticating requests to Amazon S3. for authenticating requests to Amazon S3.

6
doc/manual/src/package-management/ssh-substituter.md
View file

@ -1,6 +1,6 @@
# Serving a Nix store via SSH # Serving a Nix store via SSH
You can tell Nix to automatically fetch needed binaries from a remote You can tell Lix to automatically fetch needed binaries from a remote
Nix store via SSH. For example, the following installs Firefox, Nix store via SSH. For example, the following installs Firefox,
automatically fetching any store paths in Firefox’s closure if they are automatically fetching any store paths in Firefox’s closure if they are
available on the server `avalon`: available on the server `avalon`:
@ -9,8 +9,8 @@ available on the server `avalon`:
$ nix-env --install --attr nixpkgs.firefox --substituters ssh://alice@avalon $ nix-env --install --attr nixpkgs.firefox --substituters ssh://alice@avalon
``` ```
This works similar to the binary cache substituter that Nix usually This works similar to the binary cache substituter that Lix usually
uses, only using SSH instead of HTTP: if a store path `P` is needed, Nix uses, only using SSH instead of HTTP: if a store path `P` is needed, Lix
will first check if it’s available in the Nix store on `avalon`. If not, will first check if it’s available in the Nix store on `avalon`. If not,
it will fall back to using the binary cache substituter, and then to it will fall back to using the binary cache substituter, and then to
building from source. building from source.

2
doc/manual/src/protocols/protocols.md
View file

@ -1,4 +1,4 @@
# Protocols # Protocols
This chapter documents various developer-facing interfaces provided by This chapter documents various developer-facing interfaces provided by
Nix. Lix.

4
doc/manual/src/protocols/tarball-fetcher.md
View file

@ -23,11 +23,11 @@ Link: <flakeref>; rel="immutable"
*flakeref* must be a tarball flakeref. It can contain the tarball flake attributes *flakeref* must be a tarball flakeref. It can contain the tarball flake attributes
`narHash`, `rev`, `revCount` and `lastModified`. If `narHash` is included, its `narHash`, `rev`, `revCount` and `lastModified`. If `narHash` is included, its
value must be the NAR hash of the unpacked tarball (as computed via value must be the NAR hash of the unpacked tarball (as computed via
`nix hash path`). Nix checks the contents of the returned tarball `nix hash path`). Lix checks the contents of the returned tarball
against the `narHash` attribute. The `rev` and `revCount` attributes against the `narHash` attribute. The `rev` and `revCount` attributes
are useful when the tarball flake is a mirror of a fetcher type that are useful when the tarball flake is a mirror of a fetcher type that
has those attributes, such as Git or GitHub. They are not checked by has those attributes, such as Git or GitHub. They are not checked by
Nix. Lix.
``` ```
Link: <https://example.org/hello/442793d9ec0584f6a6e82fa253850c8085bb150a.tar.gz Link: <https://example.org/hello/442793d9ec0584f6a6e82fa253850c8085bb150a.tar.gz

23
doc/manual/src/quick-start.md
View file

@ -1,17 +1,30 @@
# Quick Start # Quick Start
<div class="warning">
FIXME(Lix): This chapter is quite outdated with respect to recommended practices in 2024 and needs updating.
The commands in here will work, however, and the installation section is up to date.
For more updated guidance, see the links on <https://lix.systems/resources/>
</div>
This chapter is for impatient people who don't like reading This chapter is for impatient people who don't like reading
documentation. For more in-depth information you are kindly referred documentation. For more in-depth information you are kindly referred
to subsequent chapters. to subsequent chapters.
1. Install Nix by running the following: 1. Install Lix:
On Linux and macOS the easiest way to install Lix is to run the following shell command
(as a user other than root):
```console ```console
$ curl -L https://nixos.org/nix/install | sh $ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
``` ```
For systems that **already have Nix installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
The install script will use `sudo`, so make sure you have sufficient rights. The install script will use `sudo`, so make sure you have sufficient rights.
On Linux, `--daemon` can be omitted for a single-user install.
For other installation methods, see [here](installation/installation.md). For other installation methods, see [here](installation/installation.md).
@ -90,10 +103,12 @@ to subsequent chapters.
$ nix-env --rollback $ nix-env --rollback
``` ```
1. You should periodically run the Nix garbage collector to get rid of 1. You should periodically run the Lix garbage collector to get rid of
unused packages, since uninstalls or upgrades don't actually delete unused packages, since uninstalls or upgrades don't actually delete
them: them:
```console ```console
$ nix-collect-garbage --delete-old $ nix-collect-garbage --delete-old
``` ```
N.B. on NixOS there is an option [`nix.gc.automatic`](https://nixos.org/manual/nixos/stable/options#opt-nix.gc.automatic) to enable a systemd timer to automate this task.

2
doc/manual/src/release-notes/release-notes.md
View file

@ -1 +1 @@
# Nix Release Notes # Lix Release Notes

4
src/nix/upgrade-nix.md
View file

@ -16,8 +16,8 @@ R""(
# Description # Description
This command upgrades Nix to the stable version declared in Nixpkgs. This command upgrades Lix to the latest stable version.
This stable version is defined in [nix-fallback-paths.nix](https://github.com/NixOS/nixpkgs/raw/master/nixos/modules/installer/tools/nix-fallback-paths.nix) This stable version is defined in [the Lix manifest](https://releases.lix.systems/manifest.nix)
and updated manually. It may not always be the latest tagged release. and updated manually. It may not always be the latest tagged release.
By default, it locates the directory containing the `nix` binary in the `$PATH` By default, it locates the directory containing the `nix` binary in the `$PATH`