▲

코드 포매팅 기능이 실험적으로 uv에 도입됨

 (pydevtools.com)
1P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • 새로운 uv 버전에서 코드 포매팅 기능을 실험적으로 제공함
  • uv format 명령어는 Ruff의 포매터를 내부적으로 사용하여 Python 코드를 일관되게 스타일링함
  • 기존에 별도의 도구 없이 uv만으로 간편하게 코드 정리 작업 가능함
  • 사용자는 추가 인자를 통해 형식 지정 동작을 세부 조정할 수 있음
  • 아직 실험적인 기능이므로 명령 방식, 에러 처리 등에서 변화 가능성이 존재함

개요

uv의 최신 릴리즈(0.8.13)는 Python 개발자가 오랫동안 기다렸던 실험적 명령어인 uv format 기능을 도입함. 이 기능을 통해 프로젝트 내에서 별도의 포매팅 도구를 추가로 관리하지 않고도 uv 도구만으로 코드 스타일 정리를 수행할 수 있음

uv format이란?

  • uv format 명령어는 uv 인터페이스를 통해 Python 코드 포매팅을 제공함
  • 내부적으로는 Ruff 포매터를 호출하여 코드를 자동으로 일관성 있게 정리함

개발자 참고 사항

Charlie Marsh(uv 개발자)는 Hacker News에서 다음과 같이 설명함

Ruff와 uv는 병합되는 것이 아니며, 여전히 별개의 도구임
단순히 사용자가 포매터를 별도의 도구로 인식하지 않고도 이용하도록 경험을 향상시키는 목적임
Rust 생태계의 cargo fmt와 rustfmt 관계와 유사함

사용 방법

  • uv 0.8.13 이상의 버전을 사용해야 함
  • uv format 명령어를 프로젝트 루트에서 실행하면 ruff format을 수행하는 효과가 있음
  • 실행 방식은 uv의 명령어 인터페이스를 따름

추가 인자 전달

  • uv format -- [추가 인자] 형태로 Ruff에 전달할 세부 옵션을 설정할 수 있음
  • uv의 편의성과 Ruff의 세밀한 설정을 동시에 활용 가능함

실험 단계 안내

  • 현재 기능은 실험적인 단계로, 향후 명령 방식이나 프로젝트 구조 통합 방식이 달라질 수 있음
  • 에러 처리, 출력 형식 등도 지속적으로 개선 예정임
  • 사용자 피드백을 반영하여 기능이 진화할 예정임

마무리

  • Python 프로젝트에 간편하고 일관성 있는 코드 스타일링이 필요한 경우 uv format을 적극적으로 시도해볼 수 있음
  • 실험적 도입인 만큼, 직접 사용 후 피드백을 제공하면 향후 uv의 발전에 기여할 수 있음
▲
GN⁺ 12시간전  [-]
Hacker News 의견
  • ruff가 ty와 합쳐지면 더 좋을 것 같음, uv는 패키지나 프로젝트 관리에 집중하는 게 맞고 코드 스타일 편집까지 관여하면 안 된다는 생각임, uv가 코드 파일을 수정하는 유일한 경우는 의존성 업데이트(PEP 723)일 때뿐이어야 한다고 봄
    • ruff와 uv는 합쳐지는 것이 아니고, 계속 별도 도구로 남는다는 점을 명확히 하고 싶음, 이는 포매터를 따로 신경쓰고 싶지 않은 사용자를 위한 더 단순한 경험 제공 목적임, Rust의 Cargo처럼 cargo fmt가 내부적으로 rustfmt를 실행하는 것과 유사한 구성임
    • Rust의 cargo에서 cargo fmt가 있는 방식처럼 흉내 내는 것임
    • 본질적으로 uv를 완성형 Python 패키지 매니저로 만드는 것이 목표이고, 각 부분 도구는 필요하면 개별적으로도 쓸 수 있음, 즉 uv는 Python을 위한 cargo 같은 존재이고, 빠른 타입체커만 필요하면 ty만, 포매터/린터만 필요하면 ruff만 선택해서 사용할 수 있어야 한다는 점에서 ruff와 ty를 합치는 건 그다지 의미가 없어 보임
    • 만약 언젠가 ty도 uv에 합쳐지면 어떨지도 궁금함, 모두 astral.sh에서 나오는 만큼 이것이 비전일 수도 있지만, 아직 ty는 준비가 덜 된 상태임
    • 다음 단계로는 uv lint 같은 옵션을 도입해서 내부적으로 ty를 실행하게 만드는 것이 논리적인 진화라 생각함, 이상적으로는 하나의 표준 명령어나 일련의 커맨드로 파이썬 프로젝트를 준비(포맷, 린트, 테스트, 배포)할 수 있게 되면 좋겠음, 어쩌면 이게 여기에 담긴 비전일 것 같음
  • uv를 정말 즐겨 쓰고 있지만, 불필요하게 점점 비대해지는 것 같아 조금 걱정임, 예를 들면 여러 서브 커맨드가 너무나 많은 독특한 플래그를 지원하는데, 몇몇은 거의 같은 결과를 내기도 함(uv run --no-project와 uv run --active 등), 쓸데없이 새로운 기능을 추가하기보다는 기존 도구와 문서 개선에 더 집중해 주길 바라는 마음임
    • Python 프로젝트를 안정적이고 재현 가능하며 이식성 있게 만드는 것은 정말 어려운 작업임, uv sync는 이론적으로 다시 재현 가능한 패키지 셋만 빌드해서 효용이 크지만, torch-tensorrt나 flash-attn처럼 복잡한 패키지는 환경에 따라 달라질 수밖에 없음, Python 커뮤니티는 종종 "내 컴퓨터에선 잘 된다"라는 식으로 문제를 개인화하는 경향이 있지만, 소프트웨어를 배포, 보안, 반복 가능성, 신뢰성 있게 만드는 데 드는 비용은 결코 사라지지 않고, 결국 누군가가 나중에 더 제한된 상황에서 그 비용을 치르게 됨, 이러한 다양한 사용자와 운영 요구를 모두 만족시키려고 애쓰는 것은 정말 어려운 일임
    • uv에 서브 커맨드를 추가하는 것이 왜 비대화로 여겨지는지 잘 모르겠음, 이미 uv는 복잡한 도구이고 문서화도 잘 되어 있음, 이렇게 직관적이고 자기 설명이 되는 커맨드라면 충분히 자연스럽게 추가될 수 있다고 생각함
    • uv에 대해 이야기할 때, 마치 "make 커맨드에 타겟이 너무 많다"고 말하는 것과 비슷하게 느껴짐
    • 이 옵션들이 메인 실행 파일에 내장되는지, 아니면 apt나 cargo처럼 별도 바이너리로 동작하는지 궁금함
  • 이 업데이트는 확실히 좋은 선택이라 생각함, 왜 많은 사람들이 더 나은 방향에 반대하는지 잘 모르겠음, 물론 "조금 더 불편한 방법으로 이미 할 수 있다"라는 건 맞지만, 그건 '조금 더 불편한' 것임
    • "uvx ruff format"이 한 단어 더 긴 게 나쁜 건 아닌 것 같음, 오히려 실제로 실행되는 포매터가 불명확해지거나, ruff가 자동으로 설치되는 건지, 기존처럼 툴을 다운받아 캐시하는 건지가 더 헷갈릴 수 있음
    • 강하게 공감하는 부분임, 심지어 pyproject에서 포매터를 설정할 수 있게 만들어주면 더 좋겠음
    • 가장 큰 불만은 현재로서는 다른 포매터 지원이 없어 보인다는 점임, 내 프로젝트에서 black을 쓰면 uv format이 동작하지 않음
  • 개인적으로 이 변경으로 내 소규모 팀(계리사들이 주요 멤버)의 코드 포매팅이 획기적으로 쉬워질 것 같아서 기대가 큼, uv가 파이썬 도입과 온보딩에 끼친 영향도 꽤 컸기 때문에, 코드품질을 더 쉽게 끌어올릴 방법은 언제나 환영임, 물론 ruff만 따로 쓰거나 pre-commit 구성을 할 수도 있지만, uv <기능>이라는 단순한 멘탈 모델이 팀에게 큰 도움이 됨, 다른 포매터와의 연동도 가능했으면 좋겠고, 만약 SQL/dbt 모델 포매팅까지 지원된다면 더 바랄 게 없을 듯함, 우선 써보면서 가능성을 확인해 볼 생각임
    • 그 정도로 다중 포매팅이 필요하다면 Makefile이나 justfile 같은 걸 쓰는 게 더 나을 수도 있음, 그러면 just format으로 Python/SQL/Bash/TypeScript까지 한번에 포매팅할 수 있음
  • 약간 기능 과다로 느껴짐, 1년 넘게 uv를 점점 더 많이 사용하고 있고 장점도 알겠지만, 아직까지 내 최우선 선택지는 아니고 이런 변화가 선호도를 높여주진 않을 것 같음
    • 구체적으로 이 방식이 뭐가 문제인지 궁금함, Go, Rust, Elixir 모두 이런 방법을 채택 중이고, 해당 언어 생태계에서 프로젝트 설정과 사용을 훨씬 더 수월하게 해줌, 커뮤니티가 공통 툴셋에 집중하고, 초보자와 전문가 모두에게 일관된 진입점을 제공하는 장점이 있음
    • 혹시 그렇다면 어떤 도구를 제일 선호하는지 궁금함
  • 언젠가는 ruff의 기능이 uv와 ty에 통합될 것 같음, 린팅은 코드베이스를 더 잘 이해하는 ty가 담당하면 더 똑똑해질 수 있고, 포매팅은 프로젝트 관리가 주목적인 uv가 담당하는 것이 적합함
    • ty가 이미 ruff와 같은 저장소에 있으니, 통합도 그리 먼 얘기는 아닌 듯함
  • 패키지 매니저는 운영 환경용 패키지 설치에 필수지만, 개발 전용 도구와 섞이는 건 일종의 '매력적이지만 위험한 덫' 같은 느낌임, 물론 Go와 Rust도 그렇게 하고 있지만, 근본적으로 생각해 보면 그리 좋은 구조는 아닌 것 같음
    • 정말 안 좋게 들릴 수도 있지만 cargo를 많이 써본 입장에서는 이런 '안 좋은 아이디어'가 더 많아졌으면 좋겠음, 만약 uv가 Python에서 cargo 같은 역할을 하게 된다면 Python 개발 경험이 엄청나게 좋아질 것임, 25년 넘게 Python을 쓰면서 여러 부족한 부분을 돌파해 온 입장에서 이제는 별다른 고민 없이 uv 하나로 가능해지는 것이 매우 만족스러움
  • 새로운 uv format은 사실상 uv run --with ruff ruff의 단축키임
  • 이 흐름이 정말 맘에 듦, 만약 내 의도대로라면 uv fmt라고 이름 짓고, uv vet 같은 것도 로드맵에 추가하는 게 좋을 것 같음
  • 이미 검증된 코드 포매터 도구들이 많은데 굳이 이걸 도입할 이유는 전혀 느끼지 못함, 기능만 늘어난 느낌이어서 당분간 어떤 파이프라인에도 포함하지 않을 생각임
    • uv format은 그냥 ruff format의 프론트엔드에 가까움, 새로운 포매터가 추가되는 것도 아님
    • 이미 많은 사람들이 사용하는 ruff format을 손쉽게 쓰도록 해주는 단축키에 불과하다는 점을 알고 있으면 좋겠음
답변달기