chore: rebrand Nix to Lix when it makes sense

Here's my guide so far:

$ rg '((?!(recursive).*) Nix
(?!(daemon|store|expression|Rocks!|Packages|language|derivation|archive|account|user|sandbox|flake).*))'
-g '!doc/' --pcre2

All items from this query have been tackled. For the documentation side:
that's for #162.

Additionally, all remaining references to github.com/NixOS/nix which
were not relevant were also replaced.

Fixes: #148.
Fixes: #162.
Change-Id: Ib3451fae5cb8ab8cd9ac9e4e4551284ee6794545
Signed-off-by: Raito Bezarius <raito@lix.systems>
This commit is contained in:
raito 2024-05-14 02:05:08 +02:00
parent 5312e60be6
commit b8cb7abcf0
52 changed files with 131 additions and 127 deletions

View file

@ -6,14 +6,14 @@ Read more about us at https://lix.systems.
## Installation
On Linux and macOS the easiest way to install Nix is to run the following shell command
On Linux and macOS the easiest way to install Lix is to run the following shell command
(as a user other than root):
```console
$ 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)
For systems that **already have a Nix implementation installed**, such as NixOS systems, read our [install page](https://lix.systems/install)
## Building And Developing

View file

@ -137,7 +137,7 @@ You can also build Lix for one of the [supported platforms](#platforms).
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://git.lix.systems/lix-project/lix/src/branch/main/flake.nix
- `x86_64-linux`
- `x86_64-darwin`

View file

@ -1,13 +1,13 @@
# Obtaining the Source
The most recent sources of Nix can be obtained from its [Git
repository](https://github.com/NixOS/nix). For example, the following
The most recent sources of Lix can be obtained from its [Git
repository](https://git.lix.systems/lix-project/lix). For example, the following
command will check out the latest revision into a directory called
`nix`:
```console
$ git clone https://github.com/NixOS/nix
$ git clone https://git.lix.systems/lix-project/lix
```
Likewise, specific releases can be obtained from the
[tags](https://github.com/NixOS/nix/tags) of the repository.
[tags](https://git.lix.systems/lix-project/lix/tags) of the repository.

View file

@ -22,7 +22,7 @@ to subsequent chapters.
$ 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)
For systems that **already have a Nix implementation 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.

View file

@ -240,7 +240,7 @@
system: binaryTarball nixpkgsFor.${system}.native.nix nixpkgsFor.${system}.native
);
# docker image with Nix inside
# docker image with Lix inside
dockerImage = lib.genAttrs linux64BitSystems (system: self.packages.${system}.dockerImage);
# API docs for Nix's unstable internal C++ interfaces.
@ -336,7 +336,7 @@
};
in
pkgs.runCommand "docker-image-tarball-${version}"
{ meta.description = "Docker image with Nix for ${system}"; }
{ meta.description = "Docker image with Lix for ${system}"; }
''
mkdir -p $out/nix-support
image=$out/image.tar.gz

View file

@ -13,7 +13,7 @@ let
];
};
meta.description = "Distribution-independent Nix bootstrap binaries for ${system}";
meta.description = "Distribution-independent Lix bootstrap binaries for ${system}";
in
buildPackages.runCommand "nix-binary-tarball-${version}" { inherit meta; } ''
cp ${installerClosureInfo}/registration $TMPDIR/reginfo

View file

@ -29,7 +29,7 @@ NEED_PROG(xz, xz)
AC_MSG_CHECKING([whether Perl is recent enough])
if ! $perl -e 'open(FOO, "-|", "true"); while (<FOO>) { print; }; close FOO or die;'; then
AC_MSG_RESULT(no)
AC_MSG_ERROR([Your Perl version is too old. Nix requires Perl 5.8.0 or newer.])
AC_MSG_ERROR([Your Perl version is too old. Lix requires Perl 5.8.0 or newer.])
fi
AC_MSG_RESULT(yes)

View file

@ -45,7 +45,7 @@ MixEvalArgs::MixEvalArgs()
-I /etc/nixos
```
will cause Nix to look for paths relative to `/home/eelco/Dev` and
will cause Lix to look for paths relative to `/home/eelco/Dev` and
`/etc/nixos`, in that order. This is equivalent to setting the
`NIX_PATH` environment variable to
@ -61,7 +61,7 @@ MixEvalArgs::MixEvalArgs()
-I /etc/nixos
```
will cause Nix to search for `<nixpkgs/path>` in
will cause Lix to search for `<nixpkgs/path>` in
`/home/eelco/Dev/nixpkgs-branch/path` and `/etc/nixos/nixpkgs/path`.
If a path in the Nix search path starts with `http://` or `https://`,
@ -73,7 +73,7 @@ MixEvalArgs::MixEvalArgs()
-I nixpkgs=https://github.com/NixOS/nixpkgs/archive/master.tar.gz
```
tells Nix to download and use the current contents of the `master`
tells Lix to download and use the current contents of the `master`
branch in the `nixpkgs` repository.
The URLs of the tarballs from the official `nixos.org` channels

View file

@ -71,8 +71,8 @@ struct EvalSettings : Config
Setting<bool> enableImportFromDerivation{
this, true, "allow-import-from-derivation",
R"(
By default, Nix allows you to `import` from a derivation, allowing
building at evaluation time. With this option set to false, Nix will
By default, Lix allows you to `import` from a derivation, allowing
building at evaluation time. With this option set to false, Lix will
throw an error when evaluating an expression that uses this feature,
allowing users to ensure their evaluation will not require any
builds to take place.

View file

@ -51,7 +51,7 @@ static void runFetchClosureWithRewrite(EvalState & state, const PosIdx pos, Stor
throw Error({
.msg = HintFmt(
"The 'toPath' value '%s' is input-addressed, so it can't possibly be the result of rewriting to a content-addressed path.\n\n"
"Set 'toPath' to an empty string to make Nix report the correct content-addressed path.",
"Set 'toPath' to an empty string to make Lix report the correct content-addressed path.",
state.store->printStorePath(toPath)),
.pos = state.positions[pos]
});
@ -271,7 +271,7 @@ static RegisterPrimOp primop_fetchClosure({
```
It is possible to fetch an [input-addressed store path](@docroot@/glossary.md#gloss-input-addressed-store-object) and return it as is.
However, this is the least preferred way of invoking `fetchClosure`, because it requires that the input-addressed paths are trusted by the Nix configuration.
However, this is the least preferred way of invoking `fetchClosure`, because it requires that the input-addressed paths are trusted by the Lix configuration.
**`builtins.storePath`**

View file

@ -33,7 +33,7 @@ MixCommonArgs::MixCommonArgs(const std::string & programName)
addFlag({
.longName = "option",
.description = "Set the Nix configuration setting *name* to *value* (overriding `nix.conf`).",
.description = "Set the Lix configuration setting *name* to *value* (overriding `nix.conf`).",
.category = miscCategory,
.labels = {"name", "value"},
.handler = {[this](std::string name, std::string value) {

View file

@ -124,7 +124,7 @@ void detectStackOverflow();
*
* This is called by the handler installed by detectStackOverflow().
*
* This gives Nix library consumers a limit opportunity to report the error
* This gives Lix library consumers a limit opportunity to report the error
* condition. The handler should exit the process.
* See defaultStackOverflowHandler() for a reference implementation.
*

View file

@ -243,7 +243,7 @@ struct ClientSettings
} else if (name == settings.pluginFiles.name) {
if (tokenizeString<Paths>(value) != settings.pluginFiles.get())
warn("Ignoring the client-specified plugin-files.\n"
"The client specifying plugins to the daemon never made sense, and was removed in Nix >=2.14.");
"The client specifying plugins to the daemon never made sense, and was removed in Nix.");
}
else if (trusted
|| name == settings.buildTimeout.name

View file

@ -40,12 +40,12 @@ struct FileTransferSettings : Config
this, 300, "stalled-download-timeout",
R"(
The timeout (in seconds) for receiving data from servers
during download. Nix cancels idle downloads after this
during download. Lix cancels idle downloads after this
timeout's duration.
)"};
Setting<unsigned int> tries{this, 5, "download-attempts",
"How often Nix will attempt to download a file before giving up."};
"How often Lix will attempt to download a file before giving up."};
};
extern FileTransferSettings fileTransferSettings;

View file

@ -87,7 +87,7 @@ Settings::Settings()
/* Set the build hook location
For builds we perform a self-invocation, so Nix has to be self-aware.
For builds we perform a self-invocation, so Lix has to be self-aware.
That is, it has to know where it is installed. We don't think it's sentient.
Normally, nix is installed according to `nixBinDir`, which is set at compile time,
@ -101,7 +101,7 @@ Settings::Settings()
current executable, using `getSelfExe()`.
As a last resort, we resort to `PATH`. Hopefully we find a `nix` there that's compatible.
If you're porting Nix to a new platform, that might be good enough for a while, but
If you're porting Lix to a new platform, that might be good enough for a while, but
you'll want to improve `getSelfExe()` to work on your platform.
*/
std::string nixExePath = nixBinDir + "/nix";

View file

@ -131,7 +131,7 @@ public:
Setting<bool> tryFallback{
this, false, "fallback",
R"(
If set to `true`, Nix will fall back to building from source if a
If set to `true`, Lix will fall back to building from source if a
binary substitute fails. This is equivalent to the `--fallback`
flag. The default is `false`.
)",
@ -149,9 +149,9 @@ public:
MaxBuildJobsSetting maxBuildJobs{
this, 1, "max-jobs",
R"(
This option defines the maximum number of jobs that Nix will try to
This option defines the maximum number of jobs that Lix will try to
build in parallel. The default is `1`. The special value `auto`
causes Nix to use the number of CPUs in your system. `0` is useful
causes Lix to use the number of CPUs in your system. `0` is useful
when using remote builders to prevent any local builds (except for
`preferLocalBuild` derivation attribute which executes locally
regardless). It can be overridden using the `--max-jobs` (`-j`)
@ -195,11 +195,11 @@ public:
Setting<std::string> thisSystem{
this, SYSTEM, "system",
R"(
The system type of the current Nix installation.
Nix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in [`extra-platforms`](#conf-extra-platforms).
The system type of the current Lix installation.
Lix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in [`extra-platforms`](#conf-extra-platforms).
The default value is set when Nix itself is compiled for the system it will run on.
The following system types are widely used, as [Nix is actively supported on these platforms](@docroot@/contributing/hacking.md#platforms):
The default value is set when Lix itself is compiled for the system it will run on.
The following system types are widely used, as [Lix is actively supported on these platforms](@docroot@/contributing/hacking.md#platforms):
- `x86_64-linux`
- `x86_64-darwin`
@ -210,7 +210,7 @@ public:
- `armv7l-linux`
In general, you do not have to modify this setting.
While you can force Nix to run a Darwin-specific `builder` executable on a Linux machine, the result would obviously be wrong.
While you can force Lix to run a Darwin-specific `builder` executable on a Linux machine, the result would obviously be wrong.
This value is available in the Nix language as
[`builtins.currentSystem`](@docroot@/language/builtin-constants.md#builtins-currentSystem)
@ -252,8 +252,8 @@ public:
R"(
The path to the helper program that executes remote builds.
Nix communicates with the build hook over `stdio` using a custom protocol to request builds that cannot be performed directly by the Nix daemon.
The default value is the internal Nix binary that implements remote building.
Lix communicates with the build hook over `stdio` using a custom protocol to request builds that cannot be performed directly by the Nix daemon.
The default value is the internal Lix binary that implements remote building.
> **Important**
>
@ -270,7 +270,7 @@ public:
Setting<bool> alwaysAllowSubstitutes{
this, false, "always-allow-substitutes",
R"(
If set to `true`, Nix will ignore the `allowSubstitutes` attribute in
If set to `true`, Lix will ignore the `allowSubstitutes` attribute in
derivations and always attempt to use available substituters.
For more information on `allowSubstitutes`, see [the manual chapter on advanced attributes](../language/advanced-attributes.md).
)"};
@ -278,7 +278,7 @@ public:
Setting<bool> buildersUseSubstitutes{
this, false, "builders-use-substitutes",
R"(
If set to `true`, Nix will instruct remote build machines to use
If set to `true`, Lix will instruct remote build machines to use
their own binary substitutes if available. In practical terms, this
means that remote hosts will fetch as many build dependencies as
possible from their own substitutes (e.g, from `cache.nixos.org`),
@ -317,7 +317,7 @@ public:
Setting<bool> useSubstitutes{
this, true, "substitute",
R"(
If set to `true` (default), Nix will use binary substitutes if
If set to `true` (default), Lix will use binary substitutes if
available. This option can be disabled to force building from
source.
)",
@ -326,9 +326,9 @@ public:
Setting<std::string> buildUsersGroup{
this, "", "build-users-group",
R"(
This options specifies the Unix group containing the Nix build user
accounts. In multi-user Nix installations, builds should not be
performed by the Nix account since that would allow users to
This options specifies the Unix group containing the Lix build user
accounts. In multi-user Lix installations, builds should not be
performed by the Lix account since that would allow users to
arbitrarily modify the Nix store and database by supplying specially
crafted builders; and they cannot be performed by the calling user
since that would allow him/her to influence the build result.
@ -338,11 +338,11 @@ public:
of the group specified here (as listed in `/etc/group`). Those user
accounts should not be used for any other purpose\!
Nix will never run two builds under the same user account at the
Lix will never run two builds under the same user account at the
same time. This is to prevent an obvious security hole: a malicious
user writing a Nix expression that modifies the build result of a
legitimate Nix expression being built by another user. Therefore it
is good to have as many Nix build user accounts as you can spare.
is good to have as many Lix build user accounts as you can spare.
(Remember: uids are cheap.)
The build users should have permission to create files in the Nix
@ -351,7 +351,7 @@ public:
and its mode should be `1775`.
If the build users group is empty, builds will be performed under
the uid of the Nix process (that is, the uid of the caller if
the uid of the Lix process (that is, the uid of the caller if
`NIX_REMOTE` is empty, the uid under which the Nix daemon runs if
`NIX_REMOTE` is `daemon`). Obviously, this should not be used
with a nix daemon accessible to untrusted clients.
@ -405,7 +405,7 @@ public:
Setting<bool> keepLog{
this, true, "keep-build-log",
R"(
If set to `true` (the default), Nix will write the build log of a
If set to `true` (the default), Lix will write the build log of a
derivation (i.e. the standard output and error of its builder) to
the directory `/nix/var/log/nix/drvs`. The build log can be
retrieved using the command `nix-store -l path`.
@ -468,7 +468,7 @@ public:
Setting<bool> autoOptimiseStore{
this, false, "auto-optimise-store",
R"(
If set to `true`, Nix automatically detects files in the store
If set to `true`, Lix automatically detects files in the store
that have identical contents, and replaces them with hard links to
a single copy. This saves disk space. If set to `false` (the
default), you can still run `nix-store --optimise` to get rid of
@ -519,7 +519,7 @@ public:
network).
Currently, sandboxing only work on Linux and macOS. The use of a
sandbox requires that Nix is run as root (so you should use the
sandbox requires that Lix is run as root (so you should use the
build users feature to perform the actual builds under different
users than root).
@ -545,7 +545,7 @@ public:
If the source is in the Nix store, then its closure will be added to
the sandbox as well.
Depending on how Nix was built, the default value for this option
Depending on how Lix was built, the default value for this option
may be empty or provide `/bin/sh` as a bind-mount of `bash`.
)",
{"build-chroot-dirs", "build-sandbox-paths"}};
@ -556,7 +556,7 @@ public:
Setting<bool> requireDropSupplementaryGroups{this, getuid() == 0, "require-drop-supplementary-groups",
R"(
Following the principle of least privilege,
Nix will attempt to drop supplementary groups when building with sandboxing.
Lix will attempt to drop supplementary groups when building with sandboxing.
However this can fail under some circumstances.
For example, if the user lacks the `CAP_SETGID` capability.
@ -642,7 +642,7 @@ public:
A whitespace-separated list of public keys.
At least one of the following condition must be met
for Nix to accept copying a store object from another
for Lix to accept copying a store object from another
Nix store (such as a substituter):
- the store object has been signed using a key in the trusted keys list
@ -665,14 +665,14 @@ public:
this, 60 * 60, "tarball-ttl",
R"(
The number of seconds a downloaded tarball is considered fresh. If
the cached tarball is stale, Nix will check whether it is still up
to date using the ETag header. Nix will download a new version if
the cached tarball is stale, Lix will check whether it is still up
to date using the ETag header. Lix will download a new version if
the ETag header is unsupported, or the cached ETag doesn't match.
Setting the TTL to `0` forces Nix to always check if the tarball is
Setting the TTL to `0` forces Lix to always check if the tarball is
up to date.
Nix caches tarballs in `$XDG_CACHE_HOME/nix/tarballs`.
Lix caches tarballs in `$XDG_CACHE_HOME/nix/tarballs`.
Files fetched via `NIX_PATH`, `fetchGit`, `fetchMercurial`,
`fetchTarball`, and `fetchurl` respect this TTL.
@ -701,7 +701,7 @@ public:
R"(
System types of executables that can be run on this machine.
Nix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in the [`system` option](#conf-system).
Lix will only build a given [derivation](@docroot@/language/derivations.md) locally when its `system` attribute equals any of the values specified here or in the [`system` option](#conf-system).
Setting this can be useful to build derivations locally on compatible machines:
- `i686-linux` executables can be run on `x86_64-linux` machines (set by default)
@ -748,16 +748,16 @@ public:
"substituters",
R"(
A list of [URLs of Nix stores](@docroot@/command-ref/new-cli/nix3-help-stores.md#store-url-format) to be used as substituters, separated by whitespace.
A substituter is an additional [store](@docroot@/glossary.md#gloss-store) from which Nix can obtain [store objects](@docroot@/glossary.md#gloss-store-object) instead of building them.
A substituter is an additional [store](@docroot@/glossary.md#gloss-store) from which Lix can obtain [store objects](@docroot@/glossary.md#gloss-store-object) instead of building them.
Substituters are tried based on their priority value, which each substituter can set independently.
Lower value means higher priority.
The default is `https://cache.nixos.org`, which has a priority of 40.
At least one of the following conditions must be met for Nix to use a substituter:
At least one of the following conditions must be met for Lix to use a substituter:
- The substituter is in the [`trusted-substituters`](#conf-trusted-substituters) list
- The user calling Nix is in the [`trusted-users`](#conf-trusted-users) list
- The user calling Lix is in the [`trusted-users`](#conf-trusted-users) list
In addition, each store path should be trusted as described in [`trusted-public-keys`](#conf-trusted-public-keys)
)",
@ -866,13 +866,13 @@ public:
this, 0, "download-speed",
R"(
Specify the maximum transfer rate in kilobytes per second you want
Nix to use for downloads.
Lix to use for downloads.
)"};
Setting<std::string> netrcFile{
this, fmt("%s/%s", nixConfDir, "netrc"), "netrc-file",
R"(
If set to an absolute path to a `netrc` file, Nix will use the HTTP
If set to an absolute path to a `netrc` file, Lix will use the HTTP
authentication credentials in this file when trying to download from
a remote host through HTTP or HTTPS. Defaults to
`$NIX_CONF_DIR/netrc`.
@ -898,7 +898,7 @@ public:
this, getDefaultSSLCertFile(), "ssl-cert-file",
R"(
The path of a file containing CA certificates used to
authenticate `https://` downloads. Nix by default will use
authenticate `https://` downloads. Lix by default will use
the first of the following files that exists:
1. `/etc/ssl/certs/ca-certificates.crt`
@ -915,7 +915,7 @@ public:
Setting<StringSet> ignoredAcls{
this, {"security.selinux", "system.nfs4_acl", "security.csm"}, "ignored-acls",
R"(
A list of ACLs that should be ignored, normally Nix attempts to
A list of ACLs that should be ignored, normally Lix attempts to
remove all ACLs from files and directories in the Nix store, but
some ACLs like `security.selinux` or `system.nfs4_acl` can't be
removed even by root. Therefore it's best to just ignore them.
@ -926,7 +926,7 @@ public:
this, {}, "hashed-mirrors",
R"(
A list of web servers used by `builtins.fetchurl` to obtain files by
hash. Given a hash type *ht* and a base-16 hash *h*, Nix will try to
hash. Given a hash type *ht* and a base-16 hash *h*, Lix will try to
download the file from *hashed-mirror*/*ht*/*h*. This allows files to
be downloaded even if they have disappeared from their original URI.
For example, given an example mirror `http://tarballs.nixos.org/`,
@ -939,7 +939,7 @@ public:
}
```
Nix will attempt to download this file from
Lix will attempt to download this file from
`http://tarballs.nixos.org/sha256/2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae`
first. If it is not available there, if will try the original URI.
)"};
@ -948,7 +948,7 @@ public:
this, 0, "min-free",
R"(
When free disk space in `/nix/store` drops below `min-free` during a
build, Nix performs a garbage-collection until `max-free` bytes are
build, Lix performs a garbage-collection until `max-free` bytes are
available or there is no more garbage. A value of `0` (the default)
disables this feature.
)"};
@ -983,7 +983,7 @@ public:
itself, they must be DSOs compatible with the instance of Nix
running at the time (i.e. compiled against the same headers, not
linked to any incompatible libraries). They should not be linked to
any Nix libs directly, as those will be available already at load
any Lix libs directly, as those will be available already at load
time.
If an entry in the list is a directory, all files in the directory
@ -996,7 +996,7 @@ public:
Setting<bool> allowSymlinkedStore{
this, false, "allow-symlinked-store",
R"(
If set to `true`, Nix will stop complaining if the store directory
If set to `true`, Lix will stop complaining if the store directory
(typically /nix/store) contains symlink components.
This risks making some builds "impure" because builders sometimes
@ -1009,13 +1009,13 @@ public:
Setting<bool> useXDGBaseDirectories{
this, false, "use-xdg-base-directories",
R"(
If set to `true`, Nix will conform to the [XDG Base Directory Specification] for files in `$HOME`.
If set to `true`, Lix will conform to the [XDG Base Directory Specification] for files in `$HOME`.
The environment variables used to implement this are documented in the [Environment Variables section](@docroot@/command-ref/env-common.md).
[XDG Base Directory Specification]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> **Warning**
> This changes the location of some well-known symlinks that Nix creates, which might break tools that rely on the old, non-XDG-conformant locations.
> This changes the location of some well-known symlinks that Lix creates, which might break tools that rely on the old, non-XDG-conformant locations.
In particular, the following locations change:
@ -1025,7 +1025,7 @@ public:
| `~/.nix-defexpr` | `$XDG_STATE_HOME/nix/defexpr` |
| `~/.nix-channels` | `$XDG_STATE_HOME/nix/channels` |
If you already have Nix installed and are using [profiles](@docroot@/package-management/profiles.md) or [channels](@docroot@/command-ref/nix-channel.md), you should migrate manually when you enable this option.
If you already have Lix installed and are using [profiles](@docroot@/package-management/profiles.md) or [channels](@docroot@/command-ref/nix-channel.md), you should migrate manually when you enable this option.
If `$XDG_STATE_HOME` is not set, use `$HOME/.local/state/nix` instead of `$XDG_STATE_HOME/nix`.
This can be achieved with the following shell commands:

View file

@ -5,7 +5,7 @@
* a glibc git checkout via `rg --pcre2 'define __NR_fchmodat2 (?!452)'`.
*
* The problem is that glibc 2.39 and libseccomp 2.5.5 are needed to
* get the syscall number. However, a Nix built against nixpkgs 23.11
* get the syscall number. However, a Lix built against nixpkgs 23.11
* (glibc 2.38) should still have the issue fixed without depending
* on the build environment.
*

View file

@ -18,12 +18,12 @@ struct LocalFSStoreConfig : virtual StoreConfig
const PathSetting stateDir{this,
rootDir.get() ? *rootDir.get() + "/nix/var/nix" : settings.nixStateDir,
"state",
"Directory where Nix will store state."};
"Directory where Lix will store state."};
const PathSetting logDir{this,
rootDir.get() ? *rootDir.get() + "/nix/var/log/nix" : settings.nixLogDir,
"log",
"directory where Nix will store log files."};
"directory where Lix will store log files."};
const PathSetting realStoreDir{this,
rootDir.get() ? *rootDir.get() + "/nix/store" : storeDir, "real",

View file

@ -313,13 +313,13 @@ LocalStore::LocalStore(const Params & params)
throw Error(
"Your Nix store has a database in Berkeley DB format,\n"
"which is no longer supported. To convert to the new format,\n"
"please upgrade Nix to version 0.12 first.");
"please use the original Nix version 0.12 first.");
if (curSchema < 6)
throw Error(
"Your Nix store has a database in flat file format,\n"
"which is no longer supported. To convert to the new format,\n"
"please upgrade Nix to version 1.11 first.");
"please use the original Nix version 1.11 first.");
if (!lockFile(globalLock.get(), ltWrite, false)) {
printInfo("waiting for exclusive access to the Nix store...");

View file

@ -23,6 +23,9 @@ namespace nix {
* 0.7. Version 2 was Nix 0.8 and 0.9. Version 3 is Nix 0.10.
* Version 4 is Nix 0.11. Version 5 is Nix 0.12-0.16. Version 6 is
* Nix 1.0. Version 7 is Nix 1.3. Version 10 is 2.0.
*
* Lix started at 2.90, it cannot ever go past version 10 (Nix 2.18),
* since doing so will break compatibility with future CppNix versions.
*/
const int nixSchemaVersion = 10;
@ -49,7 +52,7 @@ struct LocalStoreConfig : virtual LocalFSStoreConfig
R"(
Allow this store to be opened when its [database](@docroot@/glossary.md#gloss-nix-database) is on a read-only filesystem.
Normally Nix will attempt to open the store database in read-write mode, even for querying (when write access is not needed), causing it to fail if the database is on a read-only filesystem.
Normally Lix will attempt to open the store database in read-write mode, even for querying (when write access is not needed), causing it to fail if the database is on a read-only filesystem.
Enable read-only mode to disable locking and open the SQLite database with the [`immutable` parameter](https://www.sqlite.org/c3ref/open.html) set.

View file

@ -42,7 +42,7 @@ struct Generation
* of the generation.
*
* These store paths / objects are not unique to the generation
* within a profile. Nix tries to ensure successive generations have
* within a profile. Lix tries to ensure successive generations have
* distinct contents to avoid bloat, but nothing stops two
* non-adjacent generations from having the same contents.
*

View file

@ -196,7 +196,7 @@ struct S3BinaryCacheStoreConfig : virtual BinaryCacheStoreConfig
const Setting<std::string> profile{this, "", "profile",
R"(
The name of the AWS configuration profile to use. By default
Nix will use the `default` profile.
Lix will use the `default` profile.
)"};
const Setting<std::string> region{this, Aws::Region::US_EAST_1, "region",

View file

@ -1379,9 +1379,9 @@ std::shared_ptr<Store> openFromNonUri(const std::string & uri, const Store::Para
} catch (Error & e) {
return LocalStore::makeLocalStore(params);
}
warn("'%s' does not exist, so Nix will use '%s' as a chroot store", stateDir, chrootStore);
warn("'%s' does not exist, so Lix will use '%s' as a chroot store", stateDir, chrootStore);
} else
debug("'%s' does not exist, so Nix will use '%s' as a chroot store", stateDir, chrootStore);
debug("'%s' does not exist, so Lix will use '%s' as a chroot store", stateDir, chrootStore);
Store::Params chrootStoreParams;
chrootStoreParams["root"] = chrootStore;
// FIXME? this ignores *all* store parameters passed to this function?

View file

@ -74,7 +74,7 @@ void WorkerProto::Serialise<DerivedPath>::write(const Store & store, WorkerProto
GET_PROTOCOL_MINOR(conn.version));
},
[&](std::monostate) {
throw Error("wanted to build a derivation that is itself a build product, but protocols do not support that. Try upgrading the Nix on the other end of this connection");
throw Error("wanted to build a derivation that is itself a build product, but protocols do not support that. Try upgrading the Nix implementation on the other end of this connection");
},
}, sOrDrvPath);
}

View file

@ -13,7 +13,7 @@
namespace nix {
/**
* The Config class provides Nix runtime configurations.
* The Config class provides Lix runtime configurations.
*
* What is a Configuration?
* A collection of uniquely named Settings.

View file

@ -293,7 +293,7 @@ std::set<ExperimentalFeature> parseFeatures(const std::set<std::string> & rawFea
}
MissingExperimentalFeature::MissingExperimentalFeature(ExperimentalFeature feature)
: Error("experimental Nix feature '%1%' is disabled; use '--extra-experimental-features %1%' to override", showExperimentalFeature(feature))
: Error("experimental Lix feature '%1%' is disabled; use '--extra-experimental-features %1%' to override", showExperimentalFeature(feature))
, missingFeature(feature)
{}

View file

@ -41,7 +41,7 @@ struct LoggerSettings : Config
Setting<bool> showTrace{
this, false, "show-trace",
R"(
Whether Nix should print out a stack trace in case of Nix
Whether Lix should print out a stack trace in case of Nix
expression evaluation errors.
)"};
};

View file

@ -14,7 +14,7 @@ struct CmdConfig : virtual NixMultiCommand
std::string description() override
{
return "manipulate the Nix configuration";
return "manipulate the Lix configuration";
}
Category category() override { return catUtility; }
@ -41,7 +41,7 @@ struct CmdConfigShow : Command, MixJSON
std::string description() override
{
return "show the Nix configuration or the value of a specific setting";
return "show the Lix configuration or the value of a specific setting";
}
Category category() override { return catUtility; }

View file

@ -77,7 +77,7 @@ R""(
# Description
`nix develop` starts a `bash` shell that provides an interactive build
environment nearly identical to what Nix would use to build
environment nearly identical to what Lix would use to build
[*installable*](./nix.md#installables). Inside this shell, environment variables and shell
functions are set up so that you can interactively and incrementally
build your package.

View file

@ -22,7 +22,7 @@ This command verifies that the flake specified by flake reference
that the derivations specified by the flake's `checks` output can be
built successfully.
If the `keep-going` option is set to `true`, Nix will keep evaluating as much
If the `keep-going` option is set to `true`, Lix will keep evaluating as much
as it can and report the errors as it encounters them. Otherwise it will stop
at the first error.

View file

@ -26,7 +26,7 @@ R""(
>
> When trying to refer to a flake in a subdirectory, write `./another`
> instead of `another`.
> Otherwise Nix will try to look up the flake in the registry.
> Otherwise Lix will try to look up the flake in the registry.
# Description

View file

@ -39,7 +39,7 @@ R""(
>
> When trying to refer to a flake in a subdirectory, write `./another`
> instead of `another`.
> Otherwise Nix will try to look up the flake in the registry.
> Otherwise Lix will try to look up the flake in the registry.
# Description

View file

@ -98,7 +98,7 @@ Flakes corresponding to a local path can also be referred to by a direct path re
The semantic of such a path is as follows:
* If the directory is part of a Git repository, then the input will be treated as a `git+file:` URL, otherwise it will be treated as a `path:` url;
* If the directory doesn't contain a `flake.nix` file, then Nix will search for such a file upwards in the file system hierarchy until it finds any of:
* If the directory doesn't contain a `flake.nix` file, then Lix will search for such a file upwards in the file system hierarchy until it finds any of:
1. The Git repository root, or
2. The filesystem root (/), or
3. A folder on a different mount point.
@ -176,7 +176,7 @@ Currently the `type` attribute can be one of the following:
The `ref` attribute defaults to resolving the `HEAD` reference.
The `rev` attribute must denote a commit that exists in the branch
or tag specified by the `ref` attribute, since Nix doesn't do a full
or tag specified by the `ref` attribute, since Lix doesn't do a full
clone of the remote repository by default (and the Git protocol
doesn't allow fetching a `rev` without a known `ref`). The default
is the commit currently pointed to by `ref`.

View file

@ -1,6 +1,6 @@
R"(
Nix supports different types of stores. These are described below.
Lix supports different types of stores. These are described below.
## Store URL format
@ -22,11 +22,11 @@ instance,
--store ssh://machine.example.org?ssh-key=/path/to/my/key
```
tells Nix to access the store on a remote machine via the SSH
tells Lix to access the store on a remote machine via the SSH
protocol, using `/path/to/my/key` as the SSH private key. The
supported settings for each store type are documented below.
The special store URL `auto` causes Nix to automatically select a
The special store URL `auto` causes Lix to automatically select a
store as follows:
* Use the [local store](#local-store) `/nix/store` if `/nix/var/nix`

View file

@ -26,7 +26,7 @@ R""(
This command prints the log of a previous build of the [*installable*](./nix.md#installables) on standard output.
Nix looks for build logs in two places:
Lix looks for build logs in two places:
* In the directory `/nix/var/log/nix/drvs`, which contains logs for
locally built derivations.
@ -35,7 +35,7 @@ Nix looks for build logs in two places:
should be named `<cache>/log/<base-name-of-store-path>`, where
`store-path` is a derivation,
e.g. `https://cache.nixos.org/log/dvmig8jgrdapvbyxb1rprckdmdqx08kv-hello-2.10.drv`.
For non-derivation store paths, Nix will first try to determine the
For non-derivation store paths, Lix will first try to determine the
deriver by fetching the `.narinfo` file for this store path.
)""

View file

@ -41,10 +41,11 @@ R""(
# Description
Nix is a tool for building software, configurations and other
Lix is a tool for building software, configurations and other
artifacts in a reproducible and declarative way. For more information,
see the [Nix homepage](https://nixos.org/) or the [Nix
manual](https://nixos.org/manual/nix/stable/).
see the [Lix homepage](https://lix.systems).
Lix is a fork of the original implementation [CppNix](https://github.com/nixos/nix).
# Installables
@ -68,7 +69,7 @@ The following types of installable are supported by most commands:
- Specified with `--expr`/`-E`
For most commands, if no installable is specified, `.` is assumed.
That is, Nix will operate on the default flake output attribute of the flake in the current directory.
That is, Lix will operate on the default flake output attribute of the flake in the current directory.
### Flake output attribute
@ -99,7 +100,7 @@ way:
and `RELATIVE_FLAKE_DIR_PATH` is the path (relative to the directory
root) of the closest parent of the given path that contains a `flake.nix` within
the git repository.
If no such directory exists, then Nix will error-out.
If no such directory exists, then Lix will error-out.
Note that the search will only include files indexed by git. In particular, files
which are matched by `.gitignore` or have never been `git add`-ed will not be
@ -120,12 +121,12 @@ way:
- If the supplied path is not a git repository, then the url will have the form
`path:FLAKE_DIR_PATH` where `FLAKE_DIR_PATH` is the closest parent
of the supplied path that contains a `flake.nix` file (within the same file-system).
If no such directory exists, then Nix will error-out.
If no such directory exists, then Lix will error-out.
For example, if `/foo/bar/flake.nix` exists, then `/foo/bar/baz/` will resolve to
`path:/foo/bar`
If *attrpath* is omitted, Nix tries some default values; for most
If *attrpath* is omitted, Lix tries some default values; for most
subcommands, the default is `packages.`*system*`.default`
(e.g. `packages.x86_64-linux.default`), but some subcommands have
other defaults. If *attrpath* *is* specified, *attrpath* is
@ -243,7 +244,7 @@ operate are determined as follows:
```
* If you didn't specify the desired outputs, but the derivation has an
attribute `meta.outputsToInstall`, Nix will use those outputs. For
attribute `meta.outputsToInstall`, Lix will use those outputs. For
example, since the package `nixpkgs#libxml2` has this attribute:
```console
@ -259,7 +260,7 @@ operate are determined as follows:
[store derivation]: ../../glossary.md#gloss-store-derivation
* Otherwise, Nix will use all outputs of the derivation.
* Otherwise, Lix will use all outputs of the derivation.
# Nix stores

View file

@ -16,7 +16,7 @@ links to a single instance.
Note that you can also set `auto-optimise-store` to `true` in
`nix.conf` to perform this optimisation incrementally whenever a new
path is added to the Nix store. To make this efficient, Nix maintains
path is added to the Nix store. To make this efficient, Lix maintains
a content-addressed index of all the files in the Nix store in the
directory `/nix/store/.links/`.

View file

@ -25,9 +25,9 @@ R""(
This command tests whether a particular Nix store (specified by the
argument `--store` *url*) can be accessed. What this means is
dependent on the type of the store. For instance, for an SSH store it
means that Nix can connect to the specified machine.
means that Lix can connect to the specified machine.
If the command succeeds, Nix returns a exit code of 0 and does not
If the command succeeds, Lix returns a exit code of 0 and does not
print any output.
)""

View file

@ -48,7 +48,7 @@ struct CmdRepl : RawInstallablesCommand
void applyDefaultInstallables(std::vector<std::string> & rawInstallables) override
{
if (!experimentalFeatureSettings.isEnabled(Xp::ReplFlake) && !(file) && rawInstallables.size() >= 1) {
warn("future versions of Nix will require using `--file` to load a file");
warn("future versions of Lix will require using `--file` to load a file");
if (rawInstallables.size() > 1)
warn("more than one input file is not currently supported");
auto filePath = rawInstallables[0].data();

View file

@ -26,7 +26,7 @@ R""(
```
Note that `vim` (as of the time of writing of this page) is not an
app but a package. Thus, Nix runs the eponymous file from the `vim`
app but a package. Thus, Lix runs the eponymous file from the `vim`
package.
* Run `vim` with arguments:

View file

@ -53,18 +53,18 @@ R""(
# Description
Nix automatically determines potential runtime dependencies between
Lix automatically determines potential runtime dependencies between
store paths by scanning for the *hash parts* of store paths. For
instance, if there exists a store path
`/nix/store/9df65igwjmf2wbw0gbrrgair6piqjgmi-glibc-2.31`, and a file
inside another store path contains the string `9df65igw…`, then the
latter store path *refers* to the former, and thus might need it at
runtime. Nix always maintains the existence of the transitive closure
runtime. Lix always maintains the existence of the transitive closure
of a store path under the references relationship; it is therefore not
possible to install a store path without having all of its references
present.
Sometimes Nix packages end up with unexpected runtime dependencies;
Sometimes Lix packages end up with unexpected runtime dependencies;
for instance, a reference to a compiler might accidentally end up in a
binary, causing the former to be in the latter's closure. This kind of
*closure size bloat* is undesirable.

View file

@ -70,7 +70,7 @@ export _NIX_FORCE_HTTP=1
basicDownloadTests
# Test whether Nix notices if the NAR doesn't match the hash in the NAR info.
# Test whether Lix notices if the NAR doesn't match the hash in the NAR info.
clearStore
nar=$(ls $cacheDir/nar/*.nar.xz | head -n1)

View file

@ -18,7 +18,7 @@ nix-build build-hook.nix -A passthru.input2 \
--store "$TEST_ROOT/local" \
--option system-features bar
# Now when we go to build that downstream derivation, Nix will try to
# Now when we go to build that downstream derivation, Lix will try to
# copy our already-build `input2` to the remote store. That store object
# is input-addressed, so this will fail.

2