NixOS.kr 디스코드에 올렸는데, 다른 분들의 의견을 들어보려고 해커스펍에도 올립니다. 닉스 경험이 많지 않은 사람의 글이니, 정확하지 않을 수 있습니다. 틀린 곳이 있으면 바로 알려주세요.
※ 닉스를 처음 접하는 분들이나, 닉스로 실용적인 업무를 하시는데 문제가 없는 분들한테는 적당한 글은 아닙니다. 서두에 읽으면 도움이 될만한 분들을 추려서 알려 드리려고 하니, 의외로 필요한 분들이 없겠습니다. 실무자들은 이렇게까지 파고들며 알 필요 없고, 닉스 개발자들이야 당연히 아는 내용일테고, 입문자 분들도 역시 이런 내용으로 어렵다는 인식을 갖고 시작할 필요는 없으니까요. 그럼 남은 건 하나네요. mkDerivation 동작을 이미 아는 분들의 킬링 타임용이 되겠습니다.
외국어를 익힐 때, 문법없이 실전과 부딪히며 배우는 방법이 더 좋기는 한데, 가끔은 문법을 따로 보기 전엔 넘기 힘든 것들이 있습니다. 닉스란 외국어를 익히는데도 실제 설정 파일을 많이 보는 것이 우선이지만, 가끔 "문법"을 짚고 넘어가면 도움이 되는 것들이 있습니다.
닉스 알약 (제목이 재밌네요. 알약) 글을 보면 mkDerivation이 속성 집합을 받아, 거기에 stdenv 등 기본적인 것을 추가한 속성 집합을 만들어 derivaition 함수에 넘기는 간단한 래핑 함수임을 직관적으로 잘 설명하고 있습니다.
그런데, 실제 사용 예시들을 만나면, mkDerivation에 속성 집합을 넘기지 않고, attr: {...} 형태의 함수를 넘기는 경우를 더 자주 만납니다. 그래서, 왜 그러는지 실제 구현 코드를 보고 이유를 찾아 봤습니다.
mkDerivation =
fnOrAttrs:
if builtins.isFunction fnOrAttrs then
makeDerivationExtensible fnOrAttrs
else
makeDerivationExtensibleConst fnOrAttrs;
mkDerivation의 정의를 보면 인자로 함수를 받았느냐 아니냐에 따른 동작을 분기합니다. 단순히, stdenv에서 가져온 속성들을 추가한다면, 함수를 인자로 받지 않아도 속성 집합을 병합해주는 //의 동작만 있어도 충분합니다.
{ a = 1; } // { b = stdenv.XXX; }
하지만, 함수로 받는 이유를 찾으면, 코드가 단순하지 않습니다. 아래는 함수를 받을 때 동작하는 실제 구현 일부를 가져 왔습니다.
makeDerivationExtensible =
rattrs:
let
args = rattrs (args // { inherit finalPackage overrideAttrs; });
...
전체를 보기 전에 일단 args에서부터 머리가 좀 복잡해집니다. args가 args를 재귀 참조하고 있습니다. 보통 rattrs 매개 변수로는 아래와 같은 함수들이 들어 옵니다.
stdenv.mkDerivation (finalAttrs: {
pname = "timed";
version = "3.6.23";
...
tag = finalAttrs.version;
}
(와, 해커스펍은 코드 블록에 ANSI가 먹습니다! 지원하는 곳들이 드문데요.)
코드를 바로 분석하기 전에, 닉스의 재귀 동작을 먼저 보면 좋습니다.
재귀 생각 스트레칭
nix-repl> let r = {a = 1; b = a;}; in r
error: undefined variable 'a'
위 동작은 오류지만, 아래처럼 rec를 넣어주면 가능합니다.
nix-repl> let r = rec {a = 1; b = a;}; in r
{ a = 1; b = 1; }
※ rec동작은 Lazy 언어의 fix로 재귀를 구현하는 동작입니다. ※ 참고 Fix 함수
rec를 써서 속성 안에 정의 중인 속성에 접근할 수 있습니다. 그런데, 아래 같이 속성을 r.a 로 접근하면, rec 없이도 가능해집니다.
nix-repl> let r = {a = 1; b = r.a;}; in r
{ a = 1; b = 1; }
닉스 언어의 Lazy한 특성 때문에 가능합니다.
이제, 원래 문제와 비슷한 모양으로 넘어가 보겠습니다. 아래같은 형태로 바로 자기 자신에 재귀적으로 접근하면 무한 재귀 에러가 나지만,
nix-repl> let x = x + 1; in x
error: infinite recursion encountered
아래처럼 람다 함수에 인자로 넘기면 얘기가 달라집니다.
nix-repl> let args = (attr: {c = 1; b = attr.a + attr.c + 1;}) (args // { a = 1; }); in args
{ b = 3; c = 1; }
여기서 속성b의 정의 동작이 중요합니다. 위 내용을 nix-instantiate로 평가하면,
nix-instantiate --eval -E 'let args = (attr: {c = 1; b = attr.a + attr.c + 1;}) (args // { a = 1; }); in args'
{ b = <CODE>; c = 1; }
--eval 옵션은 WHNF까지만 평가합니다. <CODE>는 하스켈 문서에서 나오는 <thunk>와 같은, 평가가 아직 이루어지지 않은 상태를 뜻합니다. ※ Nix Evaluation Performance
b는 아직 평가가 되지 않았으니, 에러가 나지 않고, b가 필요한 순간에는 attr.a가 뭔지 알 수 있는 때가 됩니다.
attr:
{ c = 1;
b = attr.a + attr.c + 1;
}
속성 b는 아직 알 수 없는, 미래의 attr에 있는 a를 받아 써먹고,
원래는 rec없이 접근하지 못했던, c에도 attr.c로 접근이 가능합니다. (attr.c은 현재 정의하고 있는 속성셋의 c가 아니라, 매개 변수 attr로 들어온 속성셋의 c입니다.)
원래 문제로 다시 설명하면, mkDerivation에 넘기고 있는, 사용자 함수 finalAttrs: { ... }에서,
닉스 시스템이 넣어주는 stdenv 값 같은 것들과 사용자 함수내의 속성들을 섞어서 속성 정의를 할 수 있다는 얘기입니다. 아래처럼 말입니다.
tag = finalAttrs.version;
뭐하러, 이런 복잡한 개념을 쓰는가 하면, 단순히 속성 추가가 아니라, 기존 속성이 앞으로 추가 될 속성을 기반으로 정의되어야 할 때는 이렇게 해야만 합니다. 함수형 언어에선 자주 보이는, 미래값을 가져다 쓰는 재귀 패턴인데, 저는 아직 그리 익숙하진 않습니다.
![const REACTION_EMOJIS = ["❤️", "😕", "😮", "🤔", "👀"];
const DEFAULT_REACTION_EMOJI = REACTION_EMOJIS[0];](https://media.social.fedify.dev/media/01960f4a-def4-715b-a9b2-4103efbe7ed6/thumbnail.webp)
