guiwf/lix
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: rebrand Nix to Lix when it makes sense

Browse Source 
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 https://git.lix.systems/lix-project/lix/issues/162.

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

Fixes: https://git.lix.systems/lix-project/lix/issues/148.
Fixes: https://git.lix.systems/lix-project/lix/issues/162.
Change-Id: Ib3451fae5cb8ab8cd9ac9e4e4551284ee6794545
Signed-off-by: Raito Bezarius <raito@lix.systems>
This commit is contained in:
Raito Bezarius
2024-06-01 20:31:24 +02:00
parent 5312e60be6
commit b8cb7abcf0
52 changed files with 131 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/nix/config.cc
+2 -2
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; }
src/nix/develop.md
+1 -1
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.
src/nix/flake-check.md
+1 -1
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.
src/nix/flake-lock.md
+1 -1
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
src/nix/flake-update.md
+1 -1
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
src/nix/flake.md
+2 -2
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`.
src/nix/help-stores.md
+3 -3
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`
src/nix/log.md
+2 -2
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.
)""
src/nix/nix.md
+10 -9
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
src/nix/optimise-store.md
+1 -1
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/`.
src/nix/ping-store.md
+2 -2
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.
)""
src/nix/repl.cc
+1 -1
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();
src/nix/run.md
+1 -1
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:
src/nix/why-depends.md
+3 -3
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.