uv, 휠 캐시의 모든 파일을 BLAKE3 해시로 중복 제거해 로컬 캐시 10% 절감

나는 속도보다 Git 저장소에서 Python 도구를 바로 설치하고 같은 저장소로 업데이트하는 흐름 때문에 uv로 옮겼음. 패키지를 따로 빌드할 필요가 없더라.

uvx를 처음 써봤는데 스크립트를 실행할 때마다 의존성을 확인하느라 몇 초씩 걸렸음. 한 번은 의존성이 업데이트돼서 불안했고, 설치 자체는 pip보다 빨라 보였음.

Git 저장소 설치는 uv만의 장점은 아님. pip도 오래전부터 pip install git+https://github.com/some-org/repo를 지원했음.

BLAKE3는 중복 제거와 무결성 검사에 쓰기 좋음. 파일명에 해시 일부를 넣어두면 손상 확인, 중복 판정, 해시별 자동 삭제나 이름 변경 규칙을 만들 수 있음.

BLAKE3 해시는 최소 224비트임. 예시에 보인 40비트 문자열만 쓰는 것으로 이해하면 안 되고, 그 정도면 파일 백만 개쯤에서 충돌 확률이 50%가 됨.

대부분의 파일 형식은 내용 체크섬이 없어서 아쉬움. SQLite도 파일시스템에 맡기고, 파일시스템도 저장장치에 떠넘기는 경우가 많은데 zip은 형식 자체가 체크섬을 제공함.

BLAKE3는 머클 트리라 병렬 처리에 유리함. 데이터와 체크섬을 서브트리 단위로 구성하면 전송 중 일부 구간의 유효성을 검사하고 재전송할 수 있음.

ClosedAI에 속한 패키징 도구를 왜 써야 하는지 모르겠음. Astral 쪽에서 AI 코딩을 지지하는 말을 하는데, uv를 쓰면 결국 그들을 지원하는 셈임.

소프트웨어 개발자가 만든 자유 소프트웨어를 쓰는 것 자체가 사람이 하던 일을 계산으로 자동화한다는 생각을 지지하는 일임. 자동화는 컴퓨팅이 시작된 이유이기도 함.

이 글의 다른 댓글에서는 AI를 언급한 Astral 직원 댓글을 못 봤음. 그 주장은 그냥 지어낸 것 아닌가.

나는 pdm이 더 나음. pdm이 더 일찍 자리 잡았으면 Poetry 사용자도 uv가 아니라 pdm으로 옮겼을 것 같음.

그들이 나를 실직시키려 할 수도 있지만 당장은 확실하지 않음. 나는 지금 uv가 작업 흐름을 크게 단순하게 해줘서 씀.

캐시 10%를 줄이려고 복잡도를 늘리고 콜드 설치를 4% 늦추는 선택은 당연히 이득이라고 보기 어려움.

저장공간이 부족한 512GB 맥북을 써보면 생각이 달라짐. 캐시와 다운로드에서 40GB씩 계속 지워야 했고, 디스크 사용량 때문에 프로젝트 몇 개는 포기했음.