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을 손쉽게 쓰도록 해주는 단축키에 불과하다는 점을 알고 있으면 좋겠음