uv와 ty를 통합하기

Astral이 패키지·환경 관리 도구 uv와 타입 검사기 ty의 실험적 연동을 공개했습니다. PEP 723 스크립트마다 선언된 환경을 기준으로 검사하고, uv check 명령으로 프로젝트 환경 준비와 타입 검사를 한 번에 실행합니다.

주제: Python 개발 도구 타입 검사

에디터 노트

PEP 723 메타데이터를 읽어 스크립트별 환경을 준비하고 검사하는 부분은 uv와 ty를 묶는 실질적인 이점입니다. 특히 에디터에서 의존성을 직접 설치해야 했다는 경험담이 이 기능이 해결하려는 불편과 맞닿습니다. 다만 환경 준비가 의존성을 설치하며 제3자 코드를 실행할 수 있어 기본값이 아니라 선택 기능으로 제공됩니다. uv를 쓰지 않는 프로젝트도 ty를 독립적으로 사용할 수 있다는 반론은 이번 연동이 강제 통합이 아니라는 설명과 함께 봐야 합니다. 당장은 uv 사용자에게 편리한 경로를 추가한 셈이며, uv를 쓰지만 ty를 원하지 않는 프로젝트에는 이점이 자동으로 생기지 않습니다. Ruff 통합과 미사용 의존성 검사는 아직 계획이므로 현재 기능과 구분해야 합니다.

AI 요약

Astral이 uv와 ty의 실험적 연동을 공개했습니다. uv는 프로젝트의 의존성과 Python 환경을 파악하고, ty는 코드를 분석합니다. 두 도구가 프로젝트 정보를 공유하면서 PEP 723 스크립트 검사와 통합 진단 명령을 지원합니다.

PEP 723 스크립트와 에디터 지원

PEP 723은 Python 스크립트 파일 안에 의존성과 Python 버전을 선언하는 방식입니다. uv는 이미 이 메타데이터를 읽어 스크립트 실행 환경을 준비합니다. 이번 연동으로 ty도 같은 정보를 사용합니다. ty는 프로젝트 안의 스크립트를 찾아 각 스크립트에 선언된 요구사항에 맞춰 검사합니다. 저장소 안에서 스크립트마다 의존성이나 Python 버전이 달라도 각자 별도의 기준을 적용합니다.

VS Code에서 사용하려면 uv와 ty 확장 프로그램을 설치하고 settings.json에 "ty.experimental.useUv": "on"을 설정합니다. ty가 백그라운드에서 uv를 실행해 환경을 준비한 뒤 타입 검사와 자동 완성, 호버 정보, 정의로 이동 기능을 제공합니다. PEP 723에 선언된 의존성을 설치할 때 제3자 Python 코드가 실행될 수 있으므로 자동 환경 준비는 현재 선택 기능입니다. 향후 일반 Python 프로젝트에도 환경 자동 설정을 기본 지원할 계획입니다.

uv check

새 명령 uv check는 프로젝트 환경을 준비하고 필요한 의존성을 설치한 다음 ty로 검사합니다. 워크스페이스 전체를 검사하거나 --package <name>으로 패키지를 선택할 수 있고, --all-packages로 모든 패키지를 검사할 수도 있습니다. PEP 723 스크립트는 uv check --script example.py로 별도 검사합니다. uv check는 프로젝트 lockfile에 기록된 ty 버전을 사용하므로 개발자와 CI가 같은 버전을 실행하도록 구성할 수 있습니다. ty의 pre-commit 훅도 내부에서 uv check를 사용합니다.

uv 0.12.3 이상과 ty 0.0.76 이상이 필요합니다. 명령을 실행하지 않으면 기존 uv 사용 방식은 바뀌지 않으며, ty 바이너리는 처음 호출할 때 별도로 설치됩니다. 현재 연동은 ty 지원부터 시작하며, Astral은 앞으로 Ruff도 uv check에 넣어 린트와 타입 검사를 한 명령으로 제공할 계획입니다. 의존성 정보를 이용해 사용하지 않는 의존성을 찾는 검사도 예고했습니다.

Hacker News 반응

@WhyNotHugo — 이렇게 별도 도구들을 섞는 발상이 마음에 들지 않습니다. ty는 지금도 uv를 쓰지 않는 프로젝트에서 잘 작동합니다. uv에는 의견이 강하게 반영된 동작 방식과 자체 lockfile 등 많은 세부사항이 있고, 많은 사람이 이를 싫어합니다. ty를 별도 도구로 두면 일반 pip나 pip-tools 같은 다른 의존성 관리 도구와 함께 쓸 수 있습니다. ty와 uv 어느 쪽도 서로 통합될 필요가 없고, 독립 도구로 남는 편이 자연스럽습니다.
- @satvikpendem — A이면 B라고 해서 B이면 A라는 뜻은 아닙니다. ty를 따로 쓸 수 있고 이번 변경이 그걸 막지도 않습니다. uv check에서 ty를 함께 쓰는 일은 유용합니다.
- @jgalt212 — ty를 쓰는 프로젝트 중 uv가 아닌 도구로 의존성을 관리하는 곳은 아주 적을 수 있습니다.
- @jgalt212 — 하지만 uv를 쓰면서 ty는 쓰지 않는 프로젝트는 많을 수 있습니다.
@dirtbag__dad — 중간 규모 Python 프로젝트 여러 곳에서 린트와 타입 검사를 뒤늦게 도입해 봤습니다. 패키지 관리 도구의 기본 기능으로 제공하면 불필요한 수고를 많이 줄일 수 있습니다. 도구가 존재하는지조차 모르는 사람이 있다는 점도 문제입니다. 제품이 실제로 나아지는 동시에 사용법도 자연스럽게 알려주는 좋은 제품 홍보라고 생각합니다.
@xavdid — 반갑습니다. PEP 723 스크립트에서 가장 불편했던 에디터 지원 문제를 해결하는 단계입니다. 아이디어는 좋았지만 개발 중에 편집기 자동 완성을 쓰려면 같은 가상환경을 직접 만들고 의존성을 설치해야 했습니다. 작은 스크립트에서는 괜찮았지만 커지면 견디기 어려웠고, 결국 제대로 된 개발 환경을 따로 만드는 편이 나았습니다. 이 개선으로 사용성이 나아지길 기대합니다.
@bitpush — uv는 정말 좋아하지만 이번 글은 조직도를 그대로 제품에 반영한 것처럼 보입니다. uv에 타입 검사 기능이 생겼다고 설명하면 됐을 텐데, ty라는 이름이 아주 널리 알려진 것 같지는 않아 독자가 먼저 ty가 무엇인지 이해해야 합니다.
@nehalem — 단일 도구 체계를 선호하지만 Django의 특이한 동작에 대한 ty의 지원이 충분하지 않아 지금은 장점보다 제약이 먼저 느껴집니다.
@Philpax — Python에 Rust 같은 개발 경험이 한 걸음 더 가까워졌습니다.
- @LoganDark — Rust 개발 도구 경험과는 다릅니다. Clippy와 rustfmt도 Cargo와 완전히 합쳐지지 않고 별도 도구로 배포됩니다. 여러 도구 배포를 중앙화하는 쪽은 사실상 rustup뿐입니다.

원문 보기 ↗토론 보기 ↗