lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

69
active users

#Nix

4 posts4 participants0 posts today
Hackers' Pub · mkDerivation 인자로 함수를 넘기는 이유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 rerror: 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의 정의 동작이 중요합니다.attr: { c = 1; b = attr.a + attr.c + 1; }<속성 b는 아직 알 수 없는, 미래의 attr에 있는 a를 받아 써먹고,원래는 rec없이 접근하지 못했던, c에도 attr.c로 접근이 가능합니다. 원래 문제로 다시 설명하면, mkDerivation에 넘기고 있는, 사용자 함수 finalAttrs: { ... }에서,닉스 시스템이 넣어주는 stdenv 값 같은 것들과 사용자 함수내의 속성들을 섞어서 속성 정의를 할 수 있다는 얘기입니다. 아래처럼 말입니다. tag = finalAttrs.version;<뭐하러, 이런 복잡한 개념을 쓰는가 하면, 단순히 속성 추가가 아니라, 기존 속성이 앞으로 추가 될 속성을 기반으로 정의되어야 할 때는 이렇게 해야만 합니다. 함수형 언어에선 자주 보이는, 미래값을 가져다 쓰는 재귀 패턴인데, 저는 아직 그리 익숙하진 않습니다.

I have to say, my automatic dependency scanner [1] for #nix packages is already working better than expected!

So far i found unused dependencies in git [2], gst-plugins-bad [3], [4], linux-pam [5], networkmanager [6] and vlc [7]. And i don't plan on stopping! All these unused dependencies cause unnecessary strain on our CI and are trivial to clean up. Some of these dependencies are even old enough to drink!

I will give a talk about the tool at @cccda this Monday in the hopes of getting more people excited for this cleanup work, and to get ideas about improving the tool.

[1] github.com/LordGrimmauld/nix-c

[2] github.com/NixOS/nixpkgs/pull/
[3] github.com/NixOS/nixpkgs/pull/
[4] github.com/NixOS/nixpkgs/pull/
[5] github.com/NixOS/nixpkgs/pull/
[6] github.com/NixOS/nixpkgs/pull/
[7] github.com/NixOS/nixpkgs/pull/

scan nix packages for unused buildInputs. Contribute to LordGrimmauld/nix-check-deps development by creating an account on GitHub.
GitHubGitHub - LordGrimmauld/nix-check-deps: scan nix packages for unused buildInputsscan nix packages for unused buildInputs. Contribute to LordGrimmauld/nix-check-deps development by creating an account on GitHub.
Replied in thread

@katzenmann @nixos_org One of the hurdles is stabilizing an underlying feature like fetchTree. @domenkozar is doing some great work on that with an alternate implementation of it in #SNix, exposing some of the unfortunate choices that all #Nix implementations should backtrack on.

This may lead to a small change in behavior in Flakes that would not be considered acceptable normally for non-experimental parts of Nix, but will be necessary in order to fix various problems that exist within Flakes.

For a user of Flakes, this means that you may have to put up with a binary cache miss, or synchronizing your Nix update with your team, but you shouldn't have to overhaul your code or anything.

Thank y'all for the first day of #Rejekts2025 with great talks and inspiring conversations!

I am excited that I got a spot for the #LightningTalk​s.
Looking forward to present you #Kubenix a tool leveraging #NixOS modules to declare #K8s workloads fully declarative.
I will also show how its #Helm integration essentially bridges the #CloudNative and #Nix ecosystem effectively, while offering additionally type safety.

See you at 18:15 in the hall #TheNash!

Well... I went on the deepest of dives today to fix the link error I've been tangling with while working on tigerbeetle-hs!

First, GHC passes `-lm` near the beginning of the linker flags it generates when compiling an executable. Pretty normal.

Unless you're linking a shared object file compiled from Zig.

Zig's build tool chain vendors it's own versions of libc for the various target platforms. When you call 'linkSystemLibrary2` and tell it to link `"m"` and tell Zig that's it's needed... well, it ignores you.

Zig's build tool sees that you asked to link a system library once and it links libc... and nothing else.

All of this means that if you pass `-lm` before you link the Zig shared object, you get a relink error. Because Zig helpfully provides an implementation for the libc symbol (in my case, `sin`) and the linker already has an implementation for that symbol... in libm.

It looks like Zig's tool chain doesn't include any of the GNU library paths in the RPATH of the elf header and so the linker asks you to relink the library against libm... which you can't actually do with Zig's build tools.

Trying out a hack with nix's `patchelf` to add the RPATH's into the nix store for the glibc so that the object file can declare its dependency on libm's implementation and will have to work through the community to see how we can get Zig to play nicer with systems.

Replied in thread

We are hosting the 10th iteration (I forgot to toot about the previous one) of our Brussels #Nix / #NixOS / #Guix User Group Meetup next Friday, March 28th, at @HSBXL!

The lightning talks planned so far are:
- Local DNS server with CoreDNS by Hugo
- Self-hosting a Mastodon instance by @xavier and myself :)