Добро пожаловать на тринадцатую пилюлю Nix. В предыдущей двенадцатой пилюле мы рассказали о первом из базовых паттернов проектирования репозиториев. Кроме того, мы подготовили graphviz, чтобы в нашем учебном репозитории было два пакета.

Следующий паттерн проектирования, с которым мы познакомимся, называется callPackage. Подход, который здесь описан, широко применяется в nixpkgs и в сейчас является стандартом де-факто при импорте пакетов.

Удобство callPackage

В предыдущей пилюле мы продемонстрировали, как паттерн Входящие позволяет отвязать пакеты от репозитория. Это позволило нам явным образом передавать аргументы в деривацию: деривация объявляет параметры, а вызывающая сторона передаёт аргументы.

Но, как это часто бывает в языках программирования, нам приходится писать одно и то же два раза: сначала имена параметров, а затем те же самые имена аргументов.

{ input1, input2, ... }:
...

скорее всего, мы бы хотели присоединить эту деривацию к репозиторию через набор атрибутов, определенный как-то так:

rec {
  lib1 = import package1.nix { inherit input1 input2; };
  program2 = import package2.nix { inherit inputX inputY lib1; };
}

Есть две вещи, на которые стоит обратить внимание. Во-первых, эти входящие параметры часто имеют те же имена, что и атрибуты в репозитории. Во-вторых, из-за ключевого слова rec входящие параметры деривации могут ссылаться на другие пакеты в репозитории.

Вместо того, чтобы дважды передавать входящие параметры, мы можем автоматически передавать их из репозитория, переопределяя их в случае необходимости.

Для этого нам потребуется такая функция callPackage, чтобы её можно было вызывать подобным образом:

{
  lib1 = callPackage package1.nix { };
  program2 = callPackage package2.nix { someoverride = overriddenDerivation; };
}

Надо, чтобы callPackage была функцией с двумя аргументами, которая делает следующее:

Импортирует выражение, заданное в файле, который передаётся в первом аргументе, и возвращает функцию. Полученная функция возвращает деривацию пакета, при этом деривация использует паттерн Входящие.
Определяет имена аргументов функции, то есть имена входящих параметров деривации.
Передаёт значения аргументов из набора репозитория — мы назовём их значениями по умолчанию. В то же время она позволяет переопределить эти значения, если мы хотим поменять настройки деривации.

Реализуем callPackage

В этом разделе мы реализуем паттерн callPackage с нуля. Для начала разберёмся, как получать имена аргументов функции во время выполнения. В нашем случае речь идёт о функции, которая создаёт деривацию. Зная имена, мы сможем передавать аргументы автоматически.

Для этого Nix предоставляет встроенную функцию:

nix-repl> add = { a ? 3, b }: a+b
nix-repl> builtins.functionArgs add
{ a = true; b = false; }

Вместе с именами аргументов, набор атрибутов, возвращаемый functionArgs содержит признак, есть ли у аргумента значение по умолчанию. Сейчас для наших целей достаточно только имён аргументов.

Следующий шаг — сделать так, чтобы callPackage автоматически передавал значения аргументов в нашу деривацию, основываясь на именах аргументов, которые мы узнали благодаря functionArgs.

Для этого нам нужны две вещи:

Набор репозитория с деривациями, чьи имена совпадают с именам полученных нами аргументов.
Способ автоматически объединить набор атрибутов репозитория и значения, полученные из functionArgs.

Чтобы достичь первой цели, достаточно в качестве имён аргументов использовать имена пакетов репозитория, например, nixpkgs. Вторая цель достигается благодаря ещё одной встроенной функции Nix:

nix-repl> values = { a = 3; b = 5; c = 10; }
nix-repl> builtins.intersectAttrs values (builtins.functionArgs add)
{ a = true; b = false; }
nix-repl> builtins.intersectAttrs (builtins.functionArgs add) values
{ a = 3; b = 5; }

intersectAttrs возвращает набор атрибутов, имена которых — это пересечение имён атрибутов обоих аргументов, а значения получены из второго аргумента.

Это всё, что нам нужно: мы получили имена аргументов из функции и заполнили их значениями из существующего набора атрибутов. Вот простая учебная реализация callPackage:

nix-repl> callPackage = set: f: f (builtins.intersectAttrs (builtins.functionArgs f) set)
nix-repl> callPackage values add
8
nix-repl> with values; add { inherit a b; }
8

Проанализируем этот фрагмент кода:

Мы определяем функцию callPackage.
Первый параметр функции callPackage — это набор пар имя-значение. Часть из них может совпадать с набором аргументов вызываемой фукнции.
Второй параметр — вызываемая функция.
Мы получаем имена аргументов функции и находим их пересечение с набором всех значений.
Наконец, мы вызываем функцию f с полученным пересечением.

Фрагмент выше демонстрирует, что вызов callPackage эквивалентен прямому вызову add a b.

У нас получилось почти всё, что мы хотели: мы вызываем функции автоматически, передавая им набор аргументов.
Если аргумент в наборе не найден, мы получаем ошибку (если только у функции не переменное число аргументов, объявленных через ..., как мы объясняли в пятой таблетке).

Последняя возможность, который мы хотим добиться — позволить пользователям переопределять параметры. Нам не всегда подходят значения из большого набора. Поэтому мы добавляем к callPackage третий параметр, принимающий набор переопределений:

nix-repl> callPackage = set: f: overrides: f ((builtins.intersectAttrs (builtins.functionArgs f) set) // overrides)
nix-repl> callPackage values add { }
8
nix-repl> callPackage values add { b = 12; }
15

Код довольно ясный, не смотря на выросшее количество скобок.
Здесь мы всего-навсего объединяем набор аргументов по умолчанию с набором переопределений.

Используем callPackage, чтобы упростить код репозитория

Имея на руках функцию callPackage, мы можем упростить выражение репозитория в default.nix:

let
  nixpkgs = import <nixpkgs> { };
  allPkgs = nixpkgs // pkgs;
  callPackage =
    path: overrides:
    let
      f = import path;
    in
    f ((builtins.intersectAttrs (builtins.functionArgs f) allPkgs) // overrides);
  pkgs = with nixpkgs; {
    mkDerivation = import ./autotools.nix nixpkgs;
    hello = callPackage ./hello.nix { };
    graphviz = callPackage ./graphviz.nix { };
    graphvizCore = callPackage ./graphviz.nix { gdSupport = false; };
  };
in
pkgs

Разберёмся, как это работает:

Выражение выше определяет наш собственный репозиторий пакетов, который мы называем pkgs. Он содержит пакет hello и два варианта пакета graphviz.
В выражении let мы импортируем nixpkgs. Обратите внимание, что раньше мы ссылались на это значение с помощью переменной pkgs, но теперь это имя зарезервировано за репозиторием, который мы создаём.
Нам нужен способ как-то передать pkgs в callPackage. Вместо того, чтобы напрямую вернуть набор пакетов из default.nix, мы сначала присваиваем его переменной в выражении let, что позволяет передать его в callPackage.
В целях упрощения, мы передаём в callPackage не функцию, а имя файла, из которого callPackage эту функцию импортирует. Иначе бы нам пришлось вручную импортировать каждый пакет.
Поскольку наши выражения используют пакеты из nixpkgs, в callPackage мы описываем переменную allPkgs, в которую помещаем пакеты из nixpkgs и наши пакеты.
Мы переместили функцию mkDerivation в pkgs, чтобы она передавалась в параметрах автоматически.

Обратите внимание, как легко мы переопределили аргументы для создания graphviz без gd. Кроме того, обратите внимание, как легко слить два репозитория — nixpkgs и наш pkgs!

Читатель должен заметить магическую вещь, которая здесь происходит. Чтобы определить pkgs, мы используем callPackage, а при определении callPackage мы используем pkgs. Эта магия работает благодаря ленивым вычислениям: builtins.intersectAttrs не должен знать все значения из allPkgs, чтобы найти пересечение, а только ключи, ни один из которых не требует вычисления callPackage.

Заключение

Паттерн "callPackage" значительно упростил код репозитория. Мы смогли импортировать пакеты с именованными аргументами и вызывать их автоматически, при этом пользуясь пакетами из nixpkgs.

Также мы познакомились с полезными встроенными функциями, которые позволили нам получить информацию о функциях Nix и манипулировать атрибутами. Эти встроенные функции обычно используются не для установки пакета, а, скорее, как инструменты при установке. Они описаны в Руководстве по Nix.

Создание репозитория в Nix — это эволюция разработки удобных функций для комбинирования пакетов. Эта пилюля демонстрирует, как Nix может быть универсальным инструментом для сборки и развёртывания программ и как он подходит для создания репозиториев, которые следуют нашим собственным соглашениями.

В следующей пилюле

В следующей пилюле мы поговорим о паттерне проектирования "переопределение". Пакет graphvizCore кажется простым. Он использует скрипт graphviz.nix и собирает пакет без поддержки gd.
В следующей пилюле мы посмотрим на этот процесс с другой точки зрения: может быть стоит начать с функции pkgs.graphviz и отключать gd при её вызове?

13. Nix в пилюлях: Паттерн проектирования callPackage