COSCUP 2023

Nix is a package manager capable of managing projects, configuring the whole operating system and even deploy server clusters. Beside packaging, it can also prepare a shell with those packages readily available (nix shell), the environment to build them (nix develop), and on-the-fly execution without installation (nix run).

Nix comprises a domain-specific functional programming language (Nix Language) and a hash-based package store. Almost all the factors that would influence the build result become function inputs, and the hash of their combination then determines the store paths of the package outputs. It therefore allows nearly arbitrary modification to the build process of an existing package to produce a new one, and two will not conflict against each other even when they share the same name and version or when they depends on different versions of the same library.

Nixpkgs, the official Nix package repository, contains at least 80,000 packages and their prebuilt binary (binary substitutes). Users could use one directly and enjoy the binary substitutes, or override with the overriding functions that comes with the packages and have Nix build them locally. Nixpkgs also provides functions for workflow-specific package building, automating project building and testing.

Avoiding depending on top-level directories as it does, Nix used to require all the packages to place under /nix/store, which the Nix install script sets up with superuser privileges. At that time, unprivileged Nix users only have change the store path and loose all the binary substitutes. The local chroot store feature now allows mounting specified store directory to /nix inside a Linux user namespace, and statically compiled Nix binaries are possible. Unprivileged users can now use Nix portably with one single executable.

Packages with language-specific dependency lists, can be processed by corresponding <language>2nix (e.g. poetry2nix) to generate the Nix expression automatically. The nix-based dependencies, such as Nixpkgs and <language>2nix, are specified inside flake.nix, and their Git revisions recorded in flake.lock to ensure reproducibility.

This session will also discuss the current solutions and challenge to integrate existing language-specific dependency management the Nix ecosystem taking Python development environment as an example, and introduce dream2nix, an attempt to unify the <language>2nix projects using the module-system-based package generation, a proposed future structure of Nixpkgs.

Nix 是一軟體包管理器，同時也能管理專案，部署作業系統甚至伺服器叢集。主要運行於 Linux 與 Mac 作業系統，同時也有 cross-compile 到 WASI 等平台的能力。除了建置軟體包外，也能直接準備一個能執行這些軟體的環境（ nix shell ）與建構這些軟體（ nix develop ），甚至免安裝執行（ nix run ）。

藉由內建的純函數式的語言 Nix Language 及由建置參數的 hash 定義軟體包路徑的架構，將各項影響到建置結果的因素都作為輸入值來產生軟體包的建置命令；使用者能自由套用 patch 、修改各項建置參數，不用擔心因為名稱相同或需要不同版本的函式庫而造成套件衝突。

Nix 官方的軟體包庫 Nixpkgs 當中有八萬多個軟體包，並透過 binary cache 提供預先編譯的版本。使用者能直接利用，或視需要以軟體包附帶的函數修改，於本地再編譯。Nixpkgs 當中也包含各種建置函式（ builders ），簡化打包特定程式語言或框架的流程，能用以自動化專案編譯與測試。

以往 Nix 依賴於 /nix 目錄，要在一台電腦上使用 Nix ，必須先用 super user 權限執行官方提供的安裝腳本；或是退而求其次安裝於不同目錄下，而必須重新編譯所有用到的軟體包。現在， Nix 已經能夠靜態編譯成單一的執行檔，並將指定的目錄掛接到 Linux user namespaces 中的 /nix 目錄，一般使用者就能使用。

對於帶有依賴清單的專案， Nix 透過相應的 <language>2nix 專案（例如 poetry2nix ），分析既有的設定並產生對應的 Nix expression 。使用到的各項 Nix 專案，則透過 flake.nix 來指定，並以程式產生的 flake.lock 確定每次重建專案時都連結到一樣的 Git revision 。

這次議程也將以 Python 開發環境為例，說明 Nix 生態系在整合其他程式語言本身的依賴管理系統上遇到的挑戰，曾經與目前有的方案，及 dream2nix 這項以模組系統（ module system ）統合各種 <language>2nix 專案的嘗試。