| commit fa3eac57026abcb2c908dd633dd86ca72233936a parent 385fba8592cb5a31aaf8a71bc1bbd573cc695b6b Author: sqzer <110329244+sqzer-x@users.noreply.github.com> Date: Fri, 31 Jul 2026 23:57:31 +0900 배포 채널을 curl·cargo·AUR 셋으로 못박는다 Homebrew·Snap·Nix를 조사했고 셋 다 하지 않기로 했다. 코드로 만든 건 없어서 되돌릴 것도 없지만, 근거를 안 적어 두면 같은 조사를 다시 하게 된다. 셋을 고른 기준은 승인받을 사람이 없다는 것이다. 우리가 고치면 그날 반영되고, 대상도 겹치지 않는다 — curl은 CI와 서버, cargo는 Rust를 이미 가진 사람, AUR은 Arch 사용자다. 안 하는 이유는 셋 다 "안 된다"가 아니다. Homebrew는 core의 notability 기준에 걸린다(스타·포크·워처 전부 0). 자기 탭은 오늘도 되지만 릴리스의 macOS 타깃이 aarch64 하나뿐이라 소스 빌드 formula여야 하고, 그건 `cargo install`과 거의 같은 것을 준다. Snap은 strict + home + network-bind로 기술적으로 된다. 이 도구는 홈 디렉터리 조회도 Command::new도 런타임 HTTP 클라이언트도 없다. 안 하는 건 관객 문제다 — snap의 관객은 Ubuntu 데스크톱인데 이 도구의 사용자는 이미 셋을 가진 개발자이고, 배포 문서 1순위가 ubuntu-latest에서 cargo run으로 도는 GitHub Pages라 snapd가 낄 자리가 없다. 결정적으로 개발 머신이 Arch라 snapd도 LXD도 없어 검증할 수 없다. 눈으로 확인하기 전에 완료라고 하지 않는 레포에서 그건 그냥 못 하는 것이다. Nix는 오히려 잘 맞는다. Cargo.lock이 커밋돼 있고 락에 git 소스가 0건이라 cargoLock.lockFile 한 줄로 벤더링이 끝나며, 네트워크 없는 네임스페이스에서 `cargo test --release --offline --locked`가 147개 전부 통과한다 — Nix 샌드박스가 요구하는 조건을 이미 만족한다는 뜻이다. 그런데도 미루는 건 이 머신에 nix가 없어 nix build를 돌려 볼 수 없고, Nix 사용자가 있다는 신호가 아직 없어서다. 다시 꺼낼 조건도 적어 뒀다. "있으면 좋겠다"가 아니라 그 생태계 사용자의 요청, 또는 검증할 환경이 생기는 것이다. 곁가지로 AUR README가 아직 "올리기 전"처럼 읽혀서 등록 완료 사실을 첫 줄에 적었다. 실제로 어제 올렸는데 문서만 그 이전 상태였다. Diffstat:
|
sqzass~ A static site generator written in Rust |
| git clone https://github.com/debuman/sqzass.git |