Astral, uv와 ty 실험적 통합 공개: uv check 하나로 환경 준비와 타입 검사까지

ty는 uv 없이도 잘 돌아가는데 굳이 합칠 이유가 있나 싶음. uv는 독선적인 구석도 많고 lockfile도 자체 포맷이라 pip-tools 쓰는 사람 입장에선 부담스럽더라.

A면 B라는 게 B면 A라는 뜻은 아니잖아. ty 따로 쓸 수 있고, uv check에서 ty를 같이 쓰는 건 별개임.

ty를 쓰면서 의존성 관리는 uv 안 쓰는 프로젝트는 진짜 극소수일걸.

이 독선적인 구석이 있어서 다행임. 아니었으면 지난 20년 파이썬 패키징 지옥에 계속 있었겠지.

Astral이 uv로 락인 만들려는 건 예전부터 노골적이었음. 자체 생태계로 최대한 끌어들이겠다는 거고, 앞으로 파이썬 본류랑 갈라지는 일도 나올 듯.

uv는 진짜 좋아하는데 이 글은 조직도 자랑하는 느낌임. ty가 워낙 인지도가 낮아서 독자가 ty부터 이해하고 들어와야 함.

OpenAI의 Astral 인수가 제품에 별 악영향을 안 줘서 다행임.

6개월밖에 안 됐음. 좀 지나봐야 알지.

uv가 워낙 좋아서 걱정됨. 나중에 밧줄 당길 때 크게 아플 듯.

결국엔 망칠 거임. VC 자금 받아 다른 언어로 쓰던 도구가 AI 버블 자금으로 넘어갔으니 오래 유지될 거라 믿기 어려움.

린트랑 타입 검사가 패키지 매니저 기본 기능이 되면 중형 프로젝트에서 뒤늦게 도입할 때 드는 고생이 확 줄어듦. 애초에 그런 도구가 있는지 모르는 사람이 많다는 게 문제임.

이게 러스트 경험에 한 발 더 가까워진 거지. 좋음.

그건 러스트 경험이 아님. 러스트는 clippy도 cargo랑 따로 배포하고 rustfmt도 따로임. 도구 배포를 한데 묶는 건 rustup뿐임.

PEP 723 스크립트 에디터 지원이 안 되는 게 제일 불만이었는데 이거네. 직접 venv 만들어서 의존성 깔아야 자동완성이 됐으니 스크립트가 커지면 못 쓸 수준이었음.

ty는 ruff랑 합치는 게 더 자연스러운 거 같은데.

uv가 결국 둘 다 삼킬걸.

단일 툴체인은 좋은데 ty가 Django 특유의 동작을 제대로 지원하지 않는 게 발목을 잡음.

pyrefly가 올해 트랙션을 좀 얻었는데, Astral이 타입 체커 경쟁에서 밀렸다고 보고 인기 프로젝트에 접어넣은 것 같음. uv에 이미 깔려 있으면 다른 타입 체커를 찾을 이유가 줄어드니까.