forked from lix-project/lix
Merge "Fix the pages in the manual for Lix" into main
This commit is contained in:
Gerrit Code Review
commit
106b959043
|
|
@ -1,5 +1,5 @@
|
|||
[book]
|
||||
title = "Nix Reference Manual"
|
||||
title = "Lix Reference Manual"
|
||||
|
||||
[build]
|
||||
create-missing = false
|
||||
|
|
@ -7,8 +7,10 @@ create-missing = false
|
|||
[output.html]
|
||||
additional-css = ["custom.css"]
|
||||
additional-js = ["redirects.js"]
|
||||
edit-url-template = "https://github.com/NixOS/nix/tree/master/doc/manual/{path}"
|
||||
git-repository-url = "https://github.com/NixOS/nix"
|
||||
# Using our GitHub mirror enables easier typo fixes since there is no easy way
|
||||
# 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,
|
||||
# {{#include handlebars}}, and the @generated@ syntax used within these. it mostly
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ in
|
|||
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
|
||||
entirely.
|
||||
|
||||
Now, Nix will correctly enter the debugger at both breakpoints.
|
||||
Now, Lix will correctly enter the debugger at both breakpoints.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ prs: 4093
|
|||
Add a new `eval-system` option.
|
||||
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.
|
||||
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.
|
||||
If empty (the default) `system` is used as before, so there is no breakage.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
**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.
|
||||
|
|
|
|||
|
|
@ -5,17 +5,17 @@
|
|||
- [Installation](installation/installation.md)
|
||||
- [Supported Platforms](installation/supported-platforms.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)
|
||||
- [Obtaining a Source Distribution](installation/obtaining-source.md)
|
||||
- [Building Nix from Source](installation/building-source.md)
|
||||
- [Using Nix within Docker](installation/installing-docker.md)
|
||||
- [Building Lix from Source](installation/building-source.md)
|
||||
- [Using Lix within Docker](installation/installing-docker.md)
|
||||
- [Security](installation/nix-security.md)
|
||||
- [Single-User Mode](installation/single-user.md)
|
||||
- [Multi-User Mode](installation/multi-user.md)
|
||||
- [Environment Variables](installation/env-variables.md)
|
||||
- [Upgrading Nix](installation/upgrading.md)
|
||||
- [Uninstalling Nix](installation/uninstall.md)
|
||||
- [Upgrading Lix](installation/upgrading.md)
|
||||
- [Uninstalling Lix](installation/uninstall.md)
|
||||
- [Package Management](package-management/package-management.md)
|
||||
- [Basic Package Management](package-management/basic-package-mgmt.md)
|
||||
- [Profiles](package-management/profiles.md)
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
# 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
|
||||
they are, how they interact, and their configuration trade-offs.
|
||||
|
||||
- `max-jobs`\
|
||||
Dictates how many separate derivations will be built at the same
|
||||
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.
|
||||
|
||||
- `cores`\
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 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
|
||||
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`
|
||||
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:
|
||||
|
||||
```console
|
||||
|
|
@ -59,7 +59,7 @@ checking outputs of '/nix/store/z98fasz2jqy9gs0xbvdj939p27jwda38-stable.drv'...
|
|||
/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:
|
||||
|
||||
```console
|
||||
|
|
@ -75,7 +75,7 @@ error: derivation '/nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv' may
|
|||
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:
|
||||
|
|
@ -85,7 +85,7 @@ For derivation /nix/store/cgl13lbj1w368r5z8gywipl1ifli7dhk-unstable.drv:
|
|||
> 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:
|
||||
|
||||
```console
|
||||
|
|
@ -98,7 +98,7 @@ from '/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check'
|
|||
```
|
||||
|
||||
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.
|
||||
|
||||
> []{#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.
|
||||
|
||||
`--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: some outputs of '/nix/store/hzi1h60z2qf0nb85iwnpvrai3j2w7rr6-unstable.drv'
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# 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
|
||||
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
|
||||
`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.
|
||||
|
||||
To forward a build to a remote machine, it’s required that the remote
|
||||
|
|
@ -38,12 +38,15 @@ contains Nix.
|
|||
|
||||
> **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.
|
||||
|
||||
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
|
||||
`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
|
||||
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
|
||||
cores. For instance, the machine `itchy` in the example will execute
|
||||
up to 8 builds in parallel.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
instance, the attribute
|
||||
|
||||
|
|
|
|||
|
|
@ -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 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.
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
# Updating Nix Configuration
|
||||
# Updating Lix Configuration
|
||||
|
||||
Edit `/etc/nix/nix.conf` to run our hook, by adding the following
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
Before deploying this to production, be sure to consider the
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Architecture
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -21,8 +21,8 @@ The following [concept map] shows its main components (rectangles), the objects
|
|||
| passed to
|
||||
| |
|
||||
+----------|-------------------|--------------------------------+
|
||||
| Nix | V |
|
||||
| | +-------------------------+ |
|
||||
| Nix impl.| V |
|
||||
| (Lix) | +-------------------------+ |
|
||||
| | | commmand line interface |------. |
|
||||
| | +-------------------------+ | |
|
||||
| | | | |
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 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:
|
||||
|
||||
- File
|
||||
|
|
@ -15,7 +15,7 @@ Every file system object is one of the following:
|
|||
- [Symbolic link](https://en.m.wikipedia.org/wiki/Symbolic_link)
|
||||
|
||||
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.
|
||||
A bare file or symlink can be a root file system object.
|
||||
|
|
|
|||
|
|
@ -1,2 +1,2 @@
|
|||
This section lists commands and options that you can use when you work
|
||||
with Nix.
|
||||
with Lix.
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
# Name
|
||||
|
||||
`nix.conf` - Nix configuration file
|
||||
`nix.conf` - Lix configuration file
|
||||
|
||||
# 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
|
||||
|
||||
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,6 +1,6 @@
|
|||
# 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>\
|
||||
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
|
||||
[`-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`
|
||||
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`).
|
||||
|
||||
- <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`).
|
||||
|
||||
- <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`).
|
||||
|
||||
- <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`).
|
||||
|
||||
- <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`).
|
||||
|
||||
- <span id="env-NIX_CONFIG">[`NIX_CONFIG`](#env-NIX_CONFIG)</span>\
|
||||
Applies settings from Nix configuration from the environment.
|
||||
The content is treated as if it was read from a Nix configuration file.
|
||||
Applies settings from Lix configuration from the environment.
|
||||
The content is treated as if it was read from a Lix configuration file.
|
||||
Settings are separated by the newline character.
|
||||
|
||||
- <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].
|
||||
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`.
|
||||
|
||||
- <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
|
||||
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
|
||||
should be set to `unix://path/to/socket`. Otherwise, it should be
|
||||
left unset.
|
||||
|
||||
- <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.
|
||||
|
||||
- <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
|
||||
expressions.
|
||||
|
||||
|
|
@ -108,9 +108,9 @@ Most Nix commands interpret the following environment variables:
|
|||
|
||||
## 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.
|
||||
|
||||
The following environment variables are used to determine locations of various state and configuration files:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Files
|
||||
|
||||
This section lists configuration files that you can use when you work
|
||||
with Nix.
|
||||
with Lix.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
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
|
||||
profile is a tree of symlinks to the files of the installed packages,
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Main Commands
|
||||
|
||||
This section lists commands and options that you can use when you work
|
||||
with Nix.
|
||||
with Lix.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,9 @@ Instead, it looks in a few locations, and acts on all profiles it finds there:
|
|||
> Not stable; subject to change
|
||||
>
|
||||
> 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`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Name
|
||||
|
||||
`nix-daemon` - Nix multi-user support daemon
|
||||
`nix-daemon` - Lix multi-user support daemon
|
||||
|
||||
# Synopsis
|
||||
|
||||
|
|
@ -8,6 +8,6 @@
|
|||
|
||||
# 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
|
||||
unprivileged users.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 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>
|
||||
|
||||
|
|
@ -8,12 +8,12 @@ Most Nix commands accept the following command-line options:
|
|||
|
||||
- <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`
|
||||
|
||||
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.
|
||||
|
||||
This option may be specified repeatedly.
|
||||
|
|
@ -21,11 +21,11 @@ Most Nix commands accept the following command-line options:
|
|||
|
||||
- `0` “Errors only”
|
||||
|
||||
Only print messages explaining why the Nix invocation failed.
|
||||
Only print messages explaining why the Lix invocation failed.
|
||||
|
||||
- `1` “Informational”
|
||||
|
||||
Print *useful* messages about what Nix is doing.
|
||||
Print *useful* messages about what Lix is doing.
|
||||
This is the default.
|
||||
|
||||
- `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`
|
||||
|
||||
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.
|
||||
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*
|
||||
|
||||
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.
|
||||
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.
|
||||
|
|
@ -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`
|
||||
|
||||
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.
|
||||
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).
|
||||
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, 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`
|
||||
|
||||
|
|
@ -126,18 +126,24 @@ Most Nix commands accept the following command-line options:
|
|||
|
||||
- <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.
|
||||
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.
|
||||
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>
|
||||
|
||||
When this option is used, no attempt is made to open the Nix database.
|
||||
Most Nix operations do need database access, so those operations will fail.
|
||||
When this option is used, no attempt is made to open the Lix database.
|
||||
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*
|
||||
|
||||
|
|
@ -195,8 +201,8 @@ Most Nix commands accept the following command-line options:
|
|||
|
||||
- <span id="opt-option">[`--option`](#opt-option)</span> *name* *value*
|
||||
|
||||
Set the Nix configuration option *name* to *value*.
|
||||
This overrides settings in the Nix configuration file (see nix.conf5).
|
||||
Set the Lix configuration option *name* to *value*.
|
||||
This overrides settings in the Lix configuration file (see nix.conf(5)).
|
||||
|
||||
- <span id="opt-repair">[`--repair`](#opt-repair)</span>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# 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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
**developers and system administrators** in the life-cycle of a software
|
||||
project. We particularly need to pay special attention to help and assist new
|
||||
users of Nix.
|
||||
users of Lix.
|
||||
|
||||
# Naming the `COMMANDS`
|
||||
|
||||
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**.
|
||||
|
||||
We recommend following the [Principle of Least
|
||||
|
|
@ -184,7 +184,7 @@ Initializing Nix project at `/path/to/here`.
|
|||
### Next steps
|
||||
|
||||
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
|
||||
|
|
@ -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
|
||||
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
|
||||
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.
|
||||
|
|
@ -331,7 +331,7 @@ certain `OPTIONS`, etc…)
|
|||
|
||||
## 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.
|
||||
|
||||
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": {} } }
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
This representation is extensible and preserves the ordering:
|
||||
|
|
|
|||
|
|
@ -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?
|
||||
|
||||
|
|
@ -12,7 +19,7 @@ This was a source of confusion and controversy.
|
|||
|
||||
# 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:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 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
|
||||
$ git clone https://git.lix.systems/lix-project/lix
|
||||
|
|
@ -120,13 +120,13 @@ $ meson introspect
|
|||
|
||||
## 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
|
||||
$ 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**
|
||||
>
|
||||
|
|
@ -135,7 +135,7 @@ You can also build Nix for one of the [supported 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
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ Nix can be built for various platforms, as specified in [`flake.nix`]:
|
|||
- `armv6l-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
|
||||
platform. Common solutions include [remote builders] and [binary format emulation]
|
||||
(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>]
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -212,7 +212,7 @@ For historic reasons and backward-compatibility, some CPU and OS identifiers are
|
|||
|
||||
## Compilation environments
|
||||
|
||||
Nix can be compiled using multiple environments:
|
||||
Lix can be compiled using multiple environments:
|
||||
|
||||
- `stdenv`: default;
|
||||
- `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
|
||||
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
|
||||
# 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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
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
|
||||
|
||||
You can run the whole testsuite with `make check`, or the tests for a specific component with `make libfoo-tests_RUN`.
|
||||
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.
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -85,6 +92,11 @@ Each test is a bash script.
|
|||
|
||||
### 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:
|
||||
|
||||
```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.
|
||||
|
||||
-->
|
||||
|
||||
### Debugging failing functional tests
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
<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:
|
||||
|
||||
```shell-session
|
||||
|
|
@ -186,11 +204,15 @@ For example, enter `run` to start the Nix invocation.
|
|||
|
||||
### Characterization testing
|
||||
|
||||
Occasionally, Nix 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.
|
||||
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 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.
|
||||
|
||||
<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.
|
||||
To do that, rerun the failed test(s) with `_NIX_TEST_ACCEPT=1`.
|
||||
For example:
|
||||
|
|
@ -214,14 +236,21 @@ To ensure that characterization testing doesn't make it harder to intentionally
|
|||
## Integration tests
|
||||
|
||||
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>).
|
||||
|
||||
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
|
||||
|
||||
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):
|
||||
|
||||
|
|
@ -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
|
||||
```
|
||||
|
||||
<!-- #### 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
|
||||
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
|
||||
solved this need?
|
||||
~~>
|
||||
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -57,12 +57,12 @@
|
|||
The location in the file system where store objects live. Typically
|
||||
`/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
|
||||
as a "_local_" or a "_remote_" one:
|
||||
|
||||
+ 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
|
||||
`nix` command. Local stores can be used for building derivations.
|
||||
|
||||
|
|
@ -133,7 +133,7 @@
|
|||
|
||||
- [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.
|
||||
|
||||
See the [`substituters` configuration option](./command-ref/conf-file.md#conf-substituters) for details.
|
||||
|
|
@ -159,7 +159,7 @@
|
|||
- [Nix expression]{#gloss-nix-expression}
|
||||
|
||||
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
|
||||
derivations that are stored in the Nix store. These derivations can
|
||||
then be built.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
$ 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
|
||||
default. This can be changed using `--localstatedir=path`.
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 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
|
||||
`~/.nix-profile/bin`. The first directory contains the Nix tools
|
||||
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`
|
||||
|
||||
<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
|
||||
HTTPS-intercepting man in the middle proxy, you must specify the path to
|
||||
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.
|
||||
|
||||
Set the environment variable and install Nix
|
||||
<!--
|
||||
|
||||
Set the environment variable and install Lix
|
||||
|
||||
```console
|
||||
$ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
|
||||
$ curl -L https://nixos.org/nix/install | sh
|
||||
```
|
||||
|
||||
-->
|
||||
|
||||
In the shell profile and rc files (for example, `/etc/bashrc`,
|
||||
`/etc/zshrc`), add the following line:
|
||||
|
||||
|
|
@ -39,10 +49,10 @@ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
|
|||
|
||||
> **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.
|
||||
|
||||
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`:
|
||||
|
||||
```
|
||||
|
|
@ -51,11 +61,11 @@ ssl-cert-file = /etc/ssl/my-certificate-bundle.crt
|
|||
|
||||
## 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`,
|
||||
`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
|
||||
`/etc/systemd/system/nix-daemon.service.d/override.conf` so `nix-daemon`
|
||||
will use them.
|
||||
|
|
|
|||
|
|
@ -1,38 +1,15 @@
|
|||
# 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
|
||||
|
||||
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
|
||||
```
|
||||
FIXME(Lix): Distributions section is probably good but is definitely outdated as of this writing given nobody has packaged Lix yet (2024-05-05)
|
||||
|
||||
## 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.
|
||||
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -1,5 +1,11 @@
|
|||
# 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:
|
||||
|
||||
```console
|
||||
|
|
@ -81,7 +87,7 @@ extension. The installer will also create `/etc/profile.d/nix.sh`.
|
|||
# macOS Installation
|
||||
|
||||
[]{#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
|
||||
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
|
||||
desktop; also keeps Spotlight from spending resources to index
|
||||
this volume
|
||||
<!-- TODO:
|
||||
<!~~ TODO:
|
||||
- `suid`: honor setuid? surely not? ...
|
||||
- `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
|
||||
haven't really named and catalogued the behavior, understood what
|
||||
we're fixing, and validated that all 3 components are essential.
|
||||
-->
|
||||
~~>
|
||||
- if you have FileVault enabled
|
||||
- generate an encryption password
|
||||
- put it in your system Keychain
|
||||
|
|
@ -156,3 +162,5 @@ $ ./install
|
|||
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
|
||||
file named `install-multi-user`.
|
||||
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -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
|
||||
$ docker run -ti nixos/nix
|
||||
|
|
@ -16,7 +20,7 @@ nix (Nix) 2.3.12
|
|||
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`
|
||||
(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.
|
||||
|
||||
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.bashInteractive
|
||||
|
|
@ -40,7 +44,7 @@ of runtime dependencies that are required to use Nix:
|
|||
- pkgs.cacert.out
|
||||
- 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
|
||||
the following command:
|
||||
|
|
@ -57,3 +61,4 @@ $ nix build ./\#hydraJobs.dockerImage.x86_64-linux
|
|||
$ docker load -i ./result/image.tar.gz
|
||||
$ docker run -ti nix:2.5pre20211105
|
||||
```
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -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
|
||||
can build Nix from its Git repository.
|
||||
If no binary package is available or if you want to hack on Lix, you
|
||||
can build Lix from its Git repository.
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
# 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:
|
||||
there is a single user (typically root) who performs all package
|
||||
management operations. All other users can then use the installed
|
||||
packages, but they cannot perform package management operations
|
||||
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
|
||||
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
|
||||
Trojan horse.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,15 @@
|
|||
# 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
|
||||
autoconf-archive macro collection
|
||||
(<https://www.gnu.org/software/autoconf-archive/>). These are
|
||||
|
|
@ -76,3 +86,5 @@
|
|||
RapidCheck are required, which are available at
|
||||
<https://google.github.io/googletest/> and
|
||||
<https://github.com/emil-e/rapidcheck> respectively.
|
||||
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
# 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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
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
|
||||
$ rm -rf /nix
|
||||
|
|
@ -10,7 +20,7 @@ $ rm -rf /nix
|
|||
|
||||
## 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
|
||||
|
||||
|
|
@ -24,7 +34,7 @@ If you are on Linux with systemd:
|
|||
sudo systemctl daemon-reload
|
||||
```
|
||||
|
||||
Remove files created by Nix:
|
||||
Remove files created by Lix:
|
||||
|
||||
```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
|
||||
|
|
@ -39,7 +49,7 @@ done
|
|||
sudo groupdel nixbld
|
||||
```
|
||||
|
||||
There may also be references to Nix in
|
||||
There may also be references to Lix in
|
||||
|
||||
- `/etc/bash.bashrc`
|
||||
- `/etc/bashrc`
|
||||
|
|
@ -145,3 +155,4 @@ which you may remove.
|
|||
> complete. macOS (Catalina+) directly controls root directories and its
|
||||
> read-only root will prevent you from manually deleting the empty `/nix`
|
||||
> mountpoint.
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -1,14 +1,23 @@
|
|||
# Upgrading Nix
|
||||
# Upgrading Lix
|
||||
|
||||
Multi-user Nix users on macOS can upgrade Nix by running: `sudo -i sh -c
|
||||
'nix-channel --update &&
|
||||
nix-env --install --attr nixpkgs.nix &&
|
||||
launchctl remove org.nixos.nix-daemon &&
|
||||
launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist'`
|
||||
<div class="warning">
|
||||
|
||||
Single-user installations of Nix should run this: `nix-channel --update;
|
||||
nix-env --install --attr nixpkgs.nix nixpkgs.cacert`
|
||||
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).
|
||||
|
||||
Multi-user Nix users on Linux should run this with sudo: `nix-channel
|
||||
--update; nix-env --install --attr nixpkgs.nix nixpkgs.cacert; systemctl
|
||||
daemon-reload; systemctl restart nix-daemon`
|
||||
</div>
|
||||
|
||||
**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>
|
||||
|
|
|
|||
|
|
@ -1,12 +1,8 @@
|
|||
# Introduction
|
||||
|
||||
Nix is a _purely functional package manager_. This means that it
|
||||
treats packages like values in purely functional programming languages
|
||||