Mirrors/nixos-and-flakes-book
2
0
Fork 0
mirror of https://github.com/ryan4yin/nixos-and-flakes-book synced 2024-11-10 14:54:13 +00:00
Code Issues Projects Releases Packages Wiki Activity

fix: grammar problems

Browse source
This commit is contained in:
Ryan Yin 2023-06-24 12:24:00 +08:00
parent 4dedfdf410
commit 2195c65a3a
17 changed files with 51 additions and 82 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
docs/best-practices/debug-with-nix-repl.md
View file

@ -1,7 +1,6 @@
## Debug with `nix repl`
We've used `nix repl '<nixpkgs>'` many times to check the source code in this guide, it's really a powerful tool to help us understand how things work in Nix.
We've used `nix repl '<nixpkgs>'` many times to check the source code in this guide, it's a powerful tool to help us understand how things work in Nix.
Better take a look at the help message of `nix repl`:
@ -141,4 +140,4 @@ outputs.nixosConfigurations.ai.config.home-manager.users.ryan.home.file..config/
#......
```
As you can see, we can check every attribute of my flake in the REPL after loading it, which is very convenient for debugging.
As we can see, we can check every attribute of my flake in the REPL after loading it, which is very convenient for debugging.

6
docs/best-practices/remote-deployment.md
View file

@ -1,4 +1,3 @@
## Remote deployment
Some tools like [NixOps](https://github.com/NixOS/nixops), [deploy-rs](https://github.com/serokell/deploy-rs), and [colmena](https://github.com/zhaofengli/colmena) can all be used to deploy NixOS configuration to remote hosts, but they are all too complicated for me.
@ -22,12 +21,11 @@ ssh-add ~/.ssh/ai-idols
nixos-rebuild --flake .#aquamarine --target-host 192.168.4.1 --build-host 192.168.4.1 switch --use-remote-sudo --verbose
```
The commands above will build & deploy the configuration to aquamarine, the build process will be executed on aquamarine too,
The commands above will build & deploy the configuration to `aquamarine`, the build process will be executed on `aquamarine` too,
and the `--use-remote-sudo` option indicates that we need to use sudo permission on the remote server to deploy the configuration.
If you want to build the configuration locally and deploy it to the remote server, just replace `--build-host aquamarinr` with `--build-host localhost`.
Instead of use ip address directly, we can also define some host aliases in `~/.ssh/config` or `/etc/ssh/ssh_config`, for example:
Instead of using IP address directly, we can also define some host aliases in `~/.ssh/config` or `/etc/ssh/ssh_config`, for example:
> ssh's config can be generated completely through Nix configuration, and this task is left to you.

9
docs/best-practices/run-downloaded-binaries-on-nixos.md
View file

@ -2,11 +2,11 @@
NixOS does not follow the FHS standard, so the binaries you download from the Internet will not likely work on NixOS. But there are some ways to make it work.
Here is a detailed guide which provides 10 ways to run downloaded binaries on NixOS: [Different methods to run a non-nixos executable on Nixos](https://unix.stackexchange.com/questions/522822/different-methods-to-run-a-non-nixos-executable-on-nixos), I recommend you to read it.
Here is a detailed guide that provides 10 ways to run downloaded binaries on NixOS: [Different methods to run a non-nixos executable on Nixos](https://unix.stackexchange.com/questions/522822/different-methods-to-run-a-non-nixos-executable-on-nixos), I recommend you to read it.
Among these methods, I prefer creating a FHS environment to run the binary, which is very convenient and easy to use.
Among these methods, I prefer creating an FHS environment to run the binary, which is very convenient and easy to use.
To create such an environment, add the following code to one of your nix modules:
To create such an environment, add the following code to one of your Nix modules:
```nix
{ config, pkgs, lib, ... }:
@ -42,7 +42,7 @@ To create such an environment, add the following code to one of your nix modules
}
```
after applying the updated configuration, you can run `fhs` to enter the FHS environment, and then run the binary you downloaded, e.g.
After applying the updated configuration, you can run `fhs` to enter the FHS environment, and then run the binary you downloaded, e.g.
```shell
# Activating FHS drops me in a shell which looks like a "normal" Linux
@ -57,5 +57,4 @@ $ fhs
- [Tips&Tricks for NixOS Desktop - NixOS Discourse][Tips&Tricks for NixOS Desktop - NixOS Discourse]: Just as the title says, it is a collection of tips and tricks for NixOS desktop.
[Tips&Tricks for NixOS Desktop - NixOS Discourse]: https://discourse.nixos.org/t/tips-tricks-for-nixos-desktop/28488

4
docs/best-practices/simplify-nixos-related-commands.md
View file

@ -1,6 +1,6 @@
## Simplify nixos-related commands
## Simplify NixOS-related commands
I use Makefile to simplify nixos-related commands, which is very convenient.
I use Makefile to simplify NixOS-related commands, which is very convenient.
You can also use other similar tools to do this job, here I will only introduce my usage as a reference.
My Makefile looks like this:

13
docs/introduction/advantages-and-disadvantages.md
View file

@ -1,30 +1,27 @@
## Advantages & Disadvantages of NixOS
## Advantages
- **Declarative configuration, Environment as Code, can be managed with Git**
- Nix Flakes lock dependences's version through a lock file named `flake.lock`, to ensure that the system is reproducible. This idea actually borrows from some package managers such as npm, cargo, etc.
- Nix Flakes lock dependencies' version through a lock file named `flake.lock`, to ensure that the system is reproducible. This idea actually borrows from some package managers such as npm, cargo, etc.
- Compared with Docker, Nix Flakes provides a much stronger guarantee for the reproducibility of build results, because Dockerfile is actually an imperative configuration and there is no such thing as `flake.lock` in Docker, Docker's reproducibility relies on sharing the build result(which is MUCH MORE LARGER than Dockerfile itself) through image registry(e.g. Docker Hub).
- **Highly convenient system customization capability**
- By changing a few lines of configuration, various components of NixOS can be easily customized. This is because Nix encapsulates all the underlying complex operations in nix packages and only exports concise and necessary declarative parameters.
- By changing a few lines of configuration, various components of NixOS can be easily customized. This is because Nix encapsulates all the underlying complex operations in Nix packages and only exports concise and necessary declarative parameters.
- Moreover, this modification is very safe. For example, switching between different desktop environments on NixOS is very simple and clean, you just need to change several lines of the configuration.
- **Rollback**: The system can be restored to any historical state at any time(except the state that are NOT managed by NixOS, such as docker containers, postgresql data, etc...), and NixOS even adds all old versions to the boot options by default to ensure that the system can be rolled back at any time even though it crashes. Therefore, NixOS is also considered one of the most stable Linux Systems.
- **Rollback**: The system can be restored to any historical state at any time(except the state that is NOT managed by NixOS, such as docker containers, postgresql data, etc...), and NixOS even adds all old versions to the boot options by default to ensure that the system can be rolled back at any time even though it crashes. Therefore, NixOS is also considered one of the most stable Linux Systems.
- **No dependency conflicts**: Because each software package in Nix has a unique hash, its installation path also includes this hash value, so multiple versions can coexist.
- **The community is very active, and there are quite a few third-party projects**. The official package repository, nixpkgs, has many contributors, and many people share their Nix configuration on Github/Gitlab. After browsing through it, the entire ecosystem gives me a sense of excitement in discovering a new continent.
## Disadvantages
- **High learning curve:**: If you want the system to be completely reproducible and avoid pitfalls caused by improper use, you need to learn about the entire design of Nix and manage the system in a declarative manner. You cannot blindly use `nix-env -i` (which is similar to `apt-get install`).
- **Chaotic documentation**: Flakes is still an experimental feature, and there are currently few documents introducing it, Most of the Nix community's documentation only introduces the old cli such as `nix-env`/`nix-channel`. If you want to start learning Nix directly from Flakes, you need to refer to a large number of old documents and extract what you need from them. In addition, some of Nix's current core functions are not well-documented (such as `imports` and Nix Module System), to figure out what it does, it is best to look at the source code...
- **Relatively high disk space usage**: To ensure that the system can be rolled back at any time, Nix preserves all historical environments by default, which can take up a lot of disk space. It can be a problem especially on some resource-constrained Virtual Machines.
- **Relatively high disk space usage**: To ensure that the system can be rolled back at any time, Nix preserves all historical environments by default, which can take up a lot of disk space. It can be a problem, especially on some resource-constrained Virtual Machines.
- **Error messages may be obscure**: Sometimes you may come across some strange error messages and don't understand what's going on.
`--show- Trace` may throw you a stack of errors that are of little help.
## Summary
Generally speaking, I think NixOS is suitable for developers who have some experience in using Linux and programming and want to have more control over their systems.
I don't recommend you getting started with NixOS if you are new to Linux, it can be a very painful journey.
I don't recommend you get started with NixOS if you are new to Linux, it can be a very painful journey.

8
docs/introduction/index.md
View file

@ -1,4 +1,3 @@
## Introduction to Nix & NixOS
Nix package manager is a declarative configuration management tool. Users need to declare the expected system state in some configuration, and Nix is responsible for achieving that goal.
@ -17,17 +16,16 @@ home-manager is designed to manage user-level packages & configuration files in
Due to Nix's features such as declarative and reproducible, Nix is not only used to manage desktop environments but also widely used to manage development environments, compilation environments, cloud virtual machines, container image construction, etc. [NixOps](https://github.com/NixOS/nixops) from the Nix official and [deploy-rs](https://github.com/serokell/deploy-rs) from the community are both operations tools based on Nix.
## Why NixOS?
I heard about the Nix package manager several years ago. It uses the Nix language to describe system configuration, and the Linux distribution built on top of it, can roll back the system to any historical state at any time(In fact, only the state declared by nix configuration files can be rollback). Although it sounds impressive, it requires learning a new language and writing code to install packages, I thought it was too troublesome and didn't study it at the time.
I heard about the Nix package manager several years ago. It uses the Nix language to describe system configuration, and the Linux distribution built on top of it can roll back the system to any historical state at any time(In fact, only the state declared by nix configuration files can be rollback). Although it sounds impressive, it requires learning a new language and writing code to install packages, I thought it was too troublesome and didn't study it at the time.
But I recently encountered a lot of environmental problems in the process of using EndeavourOS, and I spent a lot of energy to solve them, which made me exhausted. After thinking about it carefully, I realized that the root cause was that EndeavourOS do not have any version control and rollback mechanism, which caused the system to be unable to be restored when problems occurred.
But I recently encountered a lot of environmental problems in the process of using EndeavourOS, and I spent a lot of energy solving them, which made me exhausted. After thinking about it carefully, I realized that the root cause was that EndeavourOS do not have any version control and rollback mechanism, which caused the system to be unable to be restored when problems occurred.
So I switched to NixOS.
I am quite satisfied with NixOS, even more than expected.
The most amazing thing is, now I can restore the entire i3 environment and my commonly used softwares on a fresh NixOS host with just one command, that's really fantastic!
The most amazing thing is, now I can restore the entire i3 environment and my commonly used packages on a fresh NixOS host with just one command, that's really fantastic!
The rollback capability of NixOS gave me a lot of confidence - I no longer fear breaking the system anymore. I even tried a lot of new things on NixOS, such as hyprland compositor. (On EndeavourOS before, I wouldn't have dared to play with such new compositors - it would have been a big hassle if something went wrong with the system and I need to fix it manually through various tricks.)

7
docs/nixos-with-flakes/downgrade-or-upgrade-packages.md
View file

@ -1,4 +1,3 @@
## Downgrade or upgrade packages
After using Flakes, most people are currently using the `nixos-unstable` branch of nixpkgs. Sometimes you will encounter some bugs, such as the [chrome/vscode crash problem](https://github.com/swaywm/sway/issues/7562)
@ -6,7 +5,7 @@ After using Flakes, most people are currently using the `nixos-unstable` branch
To resolve problems, we may need to downgrade or upgrade some packages. In Flakes, all package versions and hash values are one-to-one corresponding to the git commit of their flake input.
Therefore, to downgrade or upgrade a package, we need to lock the git commit of its flake input.
For exmaple, let's add multiple nixpkgs, each using a different git commit or branch:
For example, let's add multiple nixpkgs, each using a different git commit or branch:
```nix
{
@ -57,7 +56,7 @@ For exmaple, let's add multiple nixpkgs, each using a different git commit or br
}
```
And then refer the packages from `pkgs-stable` or `pkgs-fd40cef8d` in your sub module, a home manager's sub module as an example:
And then refer to the packages from `pkgs-stable` or `pkgs-fd40cef8d` in your sub module, a home manager's sub module as an example:
```nix
{
@ -86,6 +85,6 @@ And then refer the packages from `pkgs-stable` or `pkgs-fd40cef8d` in your sub m
}
```
After adjusted the configuration, deploy it with `sudo nixos-rebuild switch`, then your firefox/chrome/vscode will be downgraded to the version corresponding to `nixpkgs-stable` or `nixpkgs-fd40cef8d`.
After adjusting the configuration, deploy it with `sudo nixos-rebuild switch`, then your firefox/chrome/vscode will be downgraded to the version corresponding to `nixpkgs-stable` or `nixpkgs-fd40cef8d`.
> according to [1000 instances of nixpkgs](https://discourse.nixos.org/t/1000-instances-of-nixpkgs/17347), it's not a good practice to use `import` in sub modules to customize `nixpkgs`, because each `import` will create a new instance of nixpkgs, which will increase the build time and memory usage as the configuration grows. So here we create all nixpkgs instances in `flake.nix` to avoid this problem.

6
docs/nixos-with-flakes/get-started-with-nixos.md
View file

@ -1,6 +1,5 @@
## Get Started with NixOS
After learning the basics of the Nix language, we can start using it to configure our NixOS. The default configuration for NixOS is located at `/etc/nixos/configuration.nix`, which contains all the declarative configuration for the system, such as time zone, language, keyboard layout, network, users, file system, boot options, etc.
If we want to modify the system state in a reproducible way (**which is also the most recommended way**), we need to manually edit `/etc/nixos/configuration.nix`, and then execute `sudo nixos-rebuild switch` to apply the modified configuration, it will generate a new system environment based on the configuration file we modified, sets the new environment as the default one, and also preserves & added the previous environment into the boot options of grub/sytemd-boot. This ensures we can always roll back to the old environment(even if the new environment fails to start).
@ -13,7 +12,7 @@ Now first, let's learn how to manage NixOS through the classic method, `/etc/nix
As I mentioned earlier, this is the classic method to configured NixOS, and also the default method currently used by NixOS. It relies on data sources configured by `nix-channel` and has no version-locking mechanism, making it difficult to ensure the reproducibility of the system.
For example, to enable ssh and add a user "ryan", simply add the following content into `/etc/nixos/configuration.nix`:
For example, to enable ssh and add a user `ryan`, simply add the following content into `/etc/nixos/configuration.nix`:
```nix
# Edit this configuration file to define what should be installed on
@ -65,12 +64,11 @@ Any reproducible changes to the system can be made by modifying `/etc/nixos/conf
All configuration options in `/etc/nixos/configuration.nix` can be found in the following places:
- By searching on Google, such as `Chrome NixOS`, which will provide NixOS informations related to Chrome. Generally, the NixOS Wiki and the source code of Nixpkgs will be among the top results.
- By searching on Google, such as `Chrome NixOS`, which will provide NixOS information related to Chrome. Generally, the NixOS Wiki and the source code of Nixpkgs will be among the top results.
- By searching for keywords in [NixOS Options Search](https://search.nixos.org/options).
- For system-level configuration, relevant documentation can be found in [Configuration - NixOS Manual](https://nixos.org/manual/nixos/unstable/index.html#ch-configuration).
- By searching for keywords directly in the source code of [nixpkgs](https://github.com/NixOS/nixpkgs) on GitHub.
## References
- [Overview of the NixOS Linux distribution](https://nixos.wiki/wiki/Overview_of_the_NixOS_Linux_distribution)

9
docs/nixos-with-flakes/introduction-to-flakes.md
View file

@ -4,16 +4,13 @@ The flakes experimental feature is a major development for Nix, it introduces a
Flakes is one of the most significant changes the nix project has ever seen.[^2]
## Warning about Flakes
The benefits of Flakes are obvious, and the entire NixOS community likes it very much. Currently, more than half of the users are using Flakes[^3], so we're pretty sure that Flakes will never be deprecated.
:warning: But **Flakes is still an experimental feature**, there are still some problems with it, so it is likely to introduce some breaking changes in the process of stablizing it, and it’s uncertain how greatly the breaking changes will be.
So overall, I still recommend everyone to use Flakes, this book is also written around NixOS and Flakes after all, but please be prepared for the problems that may be caused by the upcomming breaking changes.
Overall, I still recommend everyone to use Flakes, this book is also written around NixOS and Flakes after all, but please be prepared for the problems that may be caused by the upcomming breaking changes.
## Nix Flakes and the classic Nix
@ -35,7 +32,6 @@ Here are the classic Nix commands and related concepts that are no longer needed
> maybe `nix-env -qa` is still useful some times, which returns all packages installed in the System.
## When will flakes stablized {#when-will-flakes-stablized}
I dived into some details about flakes:
@ -47,9 +43,6 @@ I dived into some details about flakes:
After reading all of these, I feel like that flakes will eventually be stabilized in one or two years, maybe with some breaking changes.
[^1]: [Flakes - NixOS Wiki](https://nixos.wiki/index.php?title=Flakes)
[^2]: [Flakes are such an obviously good thing](https://grahamc.com/blog/flakes-are-an-obviously-good-thing/)
[^3]: [Draft: 1 year roadmap - NixOS Foundation](https://nixos-foundation.notion.site/1-year-roadmap-0dc5c2ec265a477ea65c549cd5e568a9)

14
docs/nixos-with-flakes/nixos-with-flakes-enabled.md
View file

@ -1,6 +1,5 @@
## NixOS with Flakes Enabled
### Enabling Flakes Support
Compared to the default configuration approach of NixOS, Flakes provide better reproducibility and a clearer package structure that is easier to maintain. Therefore, it is recommended to manage NixOS with Flakes.
@ -49,7 +48,7 @@ Now to learn how to write a flake, let's take a look at the official flake templ
nix flake show templates
```
The templates `templates#full` contains all possible usecases, let's take a look at it:
The templates `templates#full` contain all possible use cases, let's take a look at them:
```bash
nix flake init -t templates#full
@ -137,16 +136,13 @@ Here we defined a NixOS system called `nixos-test`, whose configuration file is
Now run `sudo nixos-rebuild switch` to apply the configuration, and no changes will be made to the system, because we imported the old configuration file in `/etc/nixos/flake.nix`, so the actual state we declared remains unchanged.
### Manage system software through Flakes
After the switch, we can now manage the system through Flakes. The most common requirement for managing a system is to install softwares. We have seen how to install packages through `environment.systemPackages` before, and these packages are all from the official nixpkgs repository.
After the switch, we can now manage the system through Flakes. The most common requirement for managing a system is to install packges. We have seen how to install packages through `environment.systemPackages` before, and these packages are all from the official nixpkgs repository.
Now let's learn how to install packages from other sources through Flakes. This is much more flexible than installing from nixpkgs directly. The most obvious benefit is that you can easily set the version of the software.
Use [helix](https://github.com/helix-editor/helix) editor as an example, first we need to add the helix as an input into `flake.nix`:
Use [helix](https://github.com/helix-editor/helix) editor as an example, first, we need to add the helix as an input into `flake.nix`:
```nix
{
@ -178,7 +174,7 @@ Use [helix](https://github.com/helix-editor/helix) editor as an example, first w
}
```
Then udpate `configuration.nix` to install `helix` from the input `helix`:
Then update `configuration.nix` to install `helix` from the input `helix`:
```nix
# Nix will automatically inject `helix` from specialArgs
@ -208,7 +204,7 @@ Now deploy the changes by `sudo nixos-rebuild switch`, and then we can start the
> You can safely skip this section if you don't need to customize the cache mirror.
To speed up package building, Nix provides <https://cache.nixos.org> to cache build results to avoid build every packages locally.
To speed up package building, Nix provides <https://cache.nixos.org> to cache build results to avoid building every package locally.
With the NixOS's classic configuration method, other cache sources can be added by using `nix-channel`, but Flakes avoids using any system-level configuration and environment variables to ensure that its build results are not affected by the environment(so the build results are reproducible).

4
docs/nixpkgs/callpackage.md
View file

@ -1,6 +1,6 @@
## pkgs.callPackage
In the previous content, We have used `import xxx.nix` to import Nix files many times, this syntax simply returns the execution result of the file, without any further processing of the it.
In the previous content, We have used `import xxx.nix` to import Nix files many times, this syntax simply returns the execution result of the file, without any further processing of it.
`pkgs.callPackage` is also used to import Nix files, its syntax is `pkgs.callPackage xxx.nix { ... }`, but unlike `import`, the Nix file imported by it must be a Derivation or a function that returns a Derivation. Its result is a Derivation(a software package) too.
@ -13,5 +13,5 @@ When the `xxx.nix` used in `pkgs.callPackge xxx.nix {...}` is a function (most N
3. Then `pkgs.callPackge` will merge its second parameter `{...}` with the attribute set obtained in the previous step, and then pass it to the function imported from `xxx.nix` and execute it.
4. Finally we get a Derivation as the result of the function execution.
So the common usage of `pkgs.callPackage` is to import custom Nix packages and used it in Nix Module.
So the common usage of `pkgs.callPackage` is to import customized Nix packages and used them in Nix Module.
For example, we wrote a `hello.nix` ourselves, and then we can use `pkgs.callPackage ./hello.nix {}` in any Nix Module to import and use it.

13
docs/nixpkgs/overlays.md
View file

@ -1,15 +1,14 @@
## Overlays
The `override` we introduced previously will generate a new Derivation, which does not affect the original Derivation in `pkgs`, and is only suitable for use as a local parameter,
if you need to override a Derivation that is also depended on by other Nix packages, then other Nix packages will still use the original Derivation.
if you need to override a Derivation that is also dependent on other Nix packages, then other Nix packages will still use the original Derivation.
To solve this problem, Nix provides the ability to use `overlays`. Simply put, `overlays` can globally modify the Derivation in `pkgs`.
In the classic Nix environment, Nix automatically applies all `overlays` configuration under the paths `~/.config/nixpkgs/overlays.nix` `~/.config/nixpkgs/overlays/*.nix`,
but in Flakes, in order to ensure the reproducibility of the system, it cannot depend on any configuration outside the Git repository, so this classic method cannot be used now.
When using Flakes to write configuration for NixOS, home Manager and NixOS both provide the `nixpkgs.overlays` option to define `overlays`, related documentation:
When using Flakes to write configuration for NixOS, home Manager and NixOS both provide the `nixpkgs.overlays` option to define `overlays`. Related documentation:
- [home-manager docs - `nixpkgs.overlays`](https://nix-community.github.io/home-manager/options.html#opt-nixpkgs.overlays)
- [nixpkgs source code - `nixpkgs.overlays`](https://github.com/NixOS/nixpkgs/blob/30d7dd7e7f2cba9c105a6906ae2c9ed419e02f17/nixos/modules/misc/nixpkgs.nix#L169)
@ -68,7 +67,7 @@ The previous example shows how to write overlays, but all overlays are written i
To resolve this problem, here is a best practice of how to manage overlays in a modular way.
First, create an `overlays` folder in the Git repository to store all overlays configuration, and then create `overlays/default.nix`, whose content is as follows:
First, create an `overlays` folder in the Git repository to store all overlays configurations, and then create `overlays/default.nix`, whose content is as follows:
```nix
args:
@ -81,7 +80,7 @@ args:
(builtins.attrNames (builtins.readDir ./.)))
```
Then you can write all overlays configuration in the `overlays` folder, an example configuration `overlays/fcitx5/default.nix` is as follows:
Then you can write all overlays configurations in the `overlays` folder, an example configuration `overlays/fcitx5/default.nix` is as follows:
```nix
# to add my custom input method, I override the default rime-data here
@ -95,7 +94,7 @@ Then you can write all overlays configuration in the `overlays` folder, an examp
})
```
I custom the `rime-data` package through the overlay shown above.
We customized the `rime-data` package through the overlay shown above.
At last, you need to load all overlays returned by `overlays/default.nix` through the `nixpkgs.overlays` option, add the following parameter to any NixOS Module to achieve this:
@ -144,7 +143,7 @@ For example, you can just add it directly in `flake.nix`:
}
```
By using this modular approach, it is very convenient to modularize all your overlays. Taking my configuration as an example, the structure of the `overlays` folder is roughly as follows:
By using this modular approach, it is very convenient to modularize all your overlays. Taking my configuration as an example, the structure of the `overlays` folder is rough as follows:
```nix
.

5
docs/nixpkgs/overriding.md
View file

@ -1,6 +1,5 @@
## Overriding
Simply put, all Nix packages in nixpkgs can be customized with `<pkg>.override {}` to define some build parameters, which returns a new Derivation that uses custom parameters. For example:
```nix
@ -9,7 +8,7 @@ pkgs.fcitx5-rime.override {rimeDataPkgs = [
];}
```
The result of this Nix expression is a new Derivation, where `rimeDataPkgs` is overridden as `[./rime-data-flypy]`, while other parameters remain their original values.
The result of this Nix expression is a new Derivation, where `rimeDataPkgs` is overridden as `[./rime-data-flypy]`, while other parameters remain at their original values.
How to know which parameters of `fcitx5-rime` can be overridden? There are several ways:
@ -39,7 +38,7 @@ stdenv.mkDerivation rec {
}
```
Instead of override the function's parameters, we can also override the attributes of the Derivation created by `stdenv.mkDerivation`.
Instead of overriding the function's parameters, we can also override the attributes of the Derivation created by `stdenv.mkDerivation`.
Take `pkgs.hello` as an example, first check the source code of this package through the method we mentioned earlier:

3
docs/other-usage-of-flakes/inputs.md
View file

@ -1,7 +1,6 @@
## Flake inputs {#flake-inputs}
The `inputs` in `flake.nix` is a attribute set, used to specify the dependencies of the current flake, there are many types of `inputs`, for example:
The `inputs` in `flake.nix` is an attribute set, used to specify the dependencies of the current flake, there are many types of `inputs`, for example:
```nix
{

2
docs/other-usage-of-flakes/intro.md
View file

@ -1,3 +1,3 @@
## Other Usage of Flakes
Up to now, we have written a lot of configuration with Flakes to manage NixOS. Here is a brief introduction to the more detailed content of the Flakes, as well as the new command lines commonly used with flakes.
Up to now, we have written a lot of configurations with Flakes to manage NixOS. Here is a brief introduction to the more detailed content of the Flakes, as well as the new command lines commonly used with flakes.

4
docs/other-usage-of-flakes/the-new-cli.md
View file

@ -1,7 +1,6 @@
## Usage of The New CLI
after enabled `nix-command` & `flake`, you can use `nix help` to get all the info of [New Nix Commands][New Nix Commands], some useful examples are listed below:
after enabling `nix-command` & `flake`, you can use `nix help` to get all the info of [New Nix Commands][New Nix Commands], some useful examples are listed below:
```bash
# `nixpkgs#ponysay` means `ponysay` from `nixpkgs` flake.
@ -36,6 +35,5 @@ nix build "nixpkgs#bat"
[Zero to Nix - Determinate Systems][Zero to Nix - Determinate Systems] is a brand new guide to get started with Nix & Flake, recommended to read for beginners.
[New Nix Commands]: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix.html
[Zero to Nix - Determinate Systems]: https://github.com/DeterminateSystems/zero-to-nix

5
docs/zh/nixos-with-flakes/introduction-to-flakes.md
View file

@ -11,7 +11,7 @@ Flakes 带来的好处是显而易见的，整个 NixOS 社区都很喜欢它，
但是 Flakes 目前仍然存在一些问题，因此在将它推向稳定的过程中，Nix 可能会引入一些不兼容的改动，这个改动的大小目前还无法确定。
因此总的来说，我仍然推荐大家使用 Flakes，毕竟这本书本身也是围绕 NixOS 与 Flakes 编写的，但是也要做好准备——未来可能需要解决一些不兼容变更带来的问题。
总的来说，我仍然推荐大家使用 Flakes，毕竟这本书本身也是围绕 NixOS 与 Flakes 编写的，但是也要做好准备——未来可能需要解决一些不兼容变更带来的问题。
## Flakes 与传统的 Nix
@ -46,9 +46,6 @@ Nix 于 2020 年推出了 `nix-command` & `flakes` 两个新特性，它们提
读完上述内容后，个人猜测，**Flakes 可能会在未来一两年内成为稳定特性**。
[^1]: [Flakes - NixOS Wiki](https://nixos.wiki/index.php?title=Flakes)
[^2]: [Flakes are such an obviously good thing](https://grahamc.com/blog/flakes-are-an-obviously-good-thing/)
[^3]: [Draft: 1 year roadmap - NixOS Foundation](https://nixos-foundation.notion.site/1-year-roadmap-0dc5c2ec265a477ea65c549cd5e568a9)