diff options
Diffstat (limited to 'doc/manual/src/package-management')
6 files changed, 63 insertions, 31 deletions
diff --git a/doc/manual/src/package-management/basic-package-mgmt.md b/doc/manual/src/package-management/basic-package-mgmt.md index e86ef7396..0d94ea231 100644 --- a/doc/manual/src/package-management/basic-package-mgmt.md +++ b/doc/manual/src/package-management/basic-package-mgmt.md @@ -1,11 +1,20 @@ # Basic Package Management +<div class="warning"> + +FIXME(Lix): This section does not document the most common modern practices in terms of avoiding channels, pinning, declarative software installation (see flakey-profile or home-manager or NixOS), or using flakes, etc. +It is, however, likely correct at a technical level. + +For more information on modern practices, see the [resources](https://lix.systems/resources) page on the Lix site. + +</div> + The main command for package management is [`nix-env`](../command-ref/nix-env.md). You can use it to install, upgrade, and erase packages, and to query what packages are installed or are available for installation. -In Nix, different users can have different “views” on the set of +In Nix systems, different users can have different “views” on the set of installed applications. That is, there might be lots of applications present on the system (possibly in many different versions), but users can have a specific selection of those active — where “active” just @@ -14,12 +23,12 @@ on the set of installed applications is called a *user environment*, which is just a directory tree consisting of symlinks to the files of the active applications. -Components are installed from a set of *Nix expressions* that tell Nix +Components are installed from a set of *Nix expressions* that tell Lix how to build those packages, including, if necessary, their -dependencies. There is a collection of Nix expressions called the +dependencies. There is a very large collection of Nix expressions called the Nixpkgs package collection that contains packages ranging from basic development stuff such as GCC and Glibc, to end-user applications like -Mozilla Firefox. (Nix is however not tied to the Nixpkgs package +Mozilla Firefox. (Lix is however not tied to the Nixpkgs package collection; you could write your own Nix expressions based on Nixpkgs, or completely new ones.) @@ -28,7 +37,7 @@ You can manually download the latest version of Nixpkgs from convenient to use the Nixpkgs [*channel*](../command-ref/nix-channel.md), since it makes it easy to stay up to date with new versions of Nixpkgs. Nixpkgs is automatically added to your list of “subscribed” channels when you -install Nix. If this is not the case for some reason, you can add it +install Lix. If this is not the case for some reason, you can add it as follows: ```console @@ -107,7 +116,7 @@ present on your system (in which case installing it into your user environment would be a very quick operation). The last one (`S`) indicates whether there is a so-called *substitute* for the package, which is Nix’s mechanism for doing binary deployment. It just means that -Nix knows that it can fetch a pre-built package from somewhere +Lix knows that it can fetch a pre-built package from somewhere (typically a network server) instead of building it locally. You can install a package using `nix-env --install --attr `. For instance, @@ -121,12 +130,12 @@ will install the package called `subversion` from `nixpkgs` channel (which is, o > **Note** > -> When you ask Nix to install a package, it will first try to get it in -> pre-compiled form from a *binary cache*. By default, Nix will use the +> When you ask Lix to install a package, it will first try to get it in +> pre-compiled form from a *binary cache*. By default, Lix will use the > binary cache <https://cache.nixos.org>; it contains binaries for most > packages in Nixpkgs. Only if no binary is available in the binary -> cache, Nix will build the package from source. So if `nix-env -> -iA nixpkgs.subversion` results in Nix building stuff from source, then either +> cache, Lix will build the package from source. So if `nix-env +> -iA nixpkgs.subversion` results in Lix building stuff from source, then either > the package is not built for your platform by the Nixpkgs build > servers, or your version of Nixpkgs is too old or too new. For > instance, if you have a very recent checkout of Nixpkgs, then the @@ -147,7 +156,7 @@ $ nix-env --uninstall subversion ``` Upgrading to a new version is just as easy. If you have a new release of -Nix Packages, you can do: +nixpkgs, you can do: ```console $ nix-env --upgrade --attr nixpkgs.subversion diff --git a/doc/manual/src/package-management/binary-cache-substituter.md b/doc/manual/src/package-management/binary-cache-substituter.md index 855eaf470..4dcf2ca3f 100644 --- a/doc/manual/src/package-management/binary-cache-substituter.md +++ b/doc/manual/src/package-management/binary-cache-substituter.md @@ -1,8 +1,21 @@ # Serving a Nix store via HTTP +<div class="warning"> + +FIXME(Lix): This section documents outdated practices. + +In particular, the Lix developers would *not* recommend using `nix-serve` as it is relatively-unmaintained Perl. +The Lix developers would recommend instead using an s3 based cache (which is what https://cache.nixos.org is), and if it is desired to self-host it, use something like [garage](https://garagehq.deuxfleurs.fr/). + +See the following projects: +- [attic](https://github.com/zhaofengli/attic) - multi-tenant cache for larger deployments, using s3 as a backend. +- [harmonia](https://github.com/nix-community/harmonia) - closer to a drop in replacement for use cases served by nix-serve + +</div> + You can easily share the Nix store of a machine via HTTP. This allows other machines to fetch store paths from that machine to speed up -installations. It uses the same *binary cache* mechanism that Nix +installations. It uses the same *binary cache* mechanism that Lix usually uses to fetch pre-built binaries from <https://cache.nixos.org>. The daemon that handles binary cache requests via HTTP, `nix-serve`, is @@ -31,20 +44,19 @@ which should print something like: WantMassQuery: 1 Priority: 30 -On the client side, you can tell Nix to use your binary cache using -`--substituters`, e.g.: +On the client side, you can tell Lix to use your binary cache using `--substituters` (assuming you are a trusted user, see `trusted-users` in nix.conf), e.g.: ```console $ nix-env --install --attr nixpkgs.firefox --substituters http://avalon:8080/ ``` -The option `substituters` tells Nix to use this binary cache in +The option `substituters` tells Lix to use this binary cache in addition to your default caches, such as <https://cache.nixos.org>. -Thus, for any path in the closure of Firefox, Nix will first check if +Thus, for any path in the closure of Firefox, Lix will first check if the path is available on the server `avalon` or another binary caches. If not, it will fall back to building from source. -You can also tell Nix to always use your binary cache by adding a line +You can also tell Lix to always use your binary cache by adding a line to the `nix.conf` configuration file like this: substituters = http://avalon:8080/ https://cache.nixos.org/ diff --git a/doc/manual/src/package-management/garbage-collection.md b/doc/manual/src/package-management/garbage-collection.md index 29a3b3101..07ca29365 100644 --- a/doc/manual/src/package-management/garbage-collection.md +++ b/doc/manual/src/package-management/garbage-collection.md @@ -6,7 +6,7 @@ is to create a new user environment that no longer contains symlinks to the “deleted” packages. Of course, since disk space is not infinite, unused packages should be -removed at some point. You can do this by running the Nix garbage +removed at some point. You can do this by running the Lix garbage collector. It will remove from the Nix store any package not used (directly or indirectly) by any generation of any profile. diff --git a/doc/manual/src/package-management/package-management.md b/doc/manual/src/package-management/package-management.md index d528112e2..274986663 100644 --- a/doc/manual/src/package-management/package-management.md +++ b/doc/manual/src/package-management/package-management.md @@ -1,4 +1,4 @@ -This chapter discusses how to do package management with Nix, i.e., +This chapter discusses how to do package management with Lix, i.e., how to obtain, install, upgrade, and erase packages. This is the “user’s” perspective of the Nix system — people who want to *create* packages should consult the chapter on the [Nix language](../language/index.md). diff --git a/doc/manual/src/package-management/s3-substituter.md b/doc/manual/src/package-management/s3-substituter.md index d8a1d9105..55182128b 100644 --- a/doc/manual/src/package-management/s3-substituter.md +++ b/doc/manual/src/package-management/s3-substituter.md @@ -1,17 +1,28 @@ # Serving a Nix store via S3 -Nix has [built-in support](@docroot@/command-ref/new-cli/nix3-help-stores.md#s3-binary-cache-store) -for storing and fetching store paths from -Amazon S3 and S3-compatible services. This uses the same *binary* -cache mechanism that Nix usually uses to fetch prebuilt binaries from +Lix has [built-in support](@docroot@/command-ref/new-cli/nix3-help-stores.md#s3-binary-cache-store) +for storing and fetching store paths from Amazon S3 and S3-compatible services. + +<div class="warning"> + +FIXME(Lix): document the correct setup to fetch from a s3 cache via HTTP rather than just through `s3://` (which works, but forces you to remain s3-like on the client side) + +</div> + +<!-- +FIXME(Lix): no it doesn't! cache.nixos.org is just http! + +This uses the same *binary* +cache mechanism that Lix usually uses to fetch prebuilt binaries from [cache.nixos.org](https://cache.nixos.org/). +--> In this example we will use the bucket named `example-nix-cache`. ## Anonymous Reads to your S3-compatible binary cache If your binary cache is publicly accessible and does not require -authentication, the simplest and easiest way to use Nix with your S3 +authentication, the simplest and easiest way to use Lix with your S3 compatible binary cache is to use the HTTP URL for that cache. For AWS S3 the binary cache URL for example bucket will be exactly @@ -48,11 +59,11 @@ Your bucket will need the following bucket policy: For AWS S3 the binary cache URL for example bucket will be exactly <s3://example-nix-cache>. -Nix will use the [default credential provider +Lix will use the [default credential provider chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html) for authenticating requests to Amazon S3. -Nix supports authenticated reads from Amazon S3 and S3 compatible binary +Lix supports authenticated reads from Amazon S3 and S3 compatible binary caches. Your bucket will need a bucket policy allowing the desired users to @@ -63,11 +74,11 @@ updated to have a restricted `Principal` to support this. ## Authenticated Writes to your S3-compatible binary cache -Nix support fully supports writing to Amazon S3 and S3 compatible +Lix support fully supports writing to Amazon S3 and S3 compatible buckets. The binary cache URL for our example bucket will be <s3://example-nix-cache>. -Nix will use the [default credential provider +Lix will use the [default credential provider chain](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html) for authenticating requests to Amazon S3. diff --git a/doc/manual/src/package-management/ssh-substituter.md b/doc/manual/src/package-management/ssh-substituter.md index bd07b97cc..44dc3ef84 100644 --- a/doc/manual/src/package-management/ssh-substituter.md +++ b/doc/manual/src/package-management/ssh-substituter.md @@ -1,6 +1,6 @@ # Serving a Nix store via SSH -You can tell Nix to automatically fetch needed binaries from a remote +You can tell Lix to automatically fetch needed binaries from a remote Nix store via SSH. For example, the following installs Firefox, automatically fetching any store paths in Firefox’s closure if they are available on the server `avalon`: @@ -9,8 +9,8 @@ available on the server `avalon`: $ nix-env --install --attr nixpkgs.firefox --substituters ssh://alice@avalon ``` -This works similar to the binary cache substituter that Nix usually -uses, only using SSH instead of HTTP: if a store path `P` is needed, Nix +This works similar to the binary cache substituter that Lix usually +uses, only using SSH instead of HTTP: if a store path `P` is needed, Lix will first check if it’s available in the Nix store on `avalon`. If not, it will fall back to using the binary cache substituter, and then to building from source. |