Rye: 번거로움 없는 Python 경험

• Rye는 Python 설치, pyproject.toml 프로젝트, 의존성, virtualenv, 전역 도구 설치를 한곳에서 다루려던 프로젝트·패키지 관리 도구임
• 현재는 개발이 중단됐고, 같은 유지관리자들이 만든 후속 프로젝트 uv 사용이 권장됨
• 기존 사용자는 uv migration guide를 참고해 이전할 수 있으며, Rye는 계속 받을 수 있지만 더 이상의 업데이트 계획은 없음
• 업데이트 중단에는 보안 업데이트도 포함돼 새 프로젝트나 장기 유지보수 환경에서는 uv 전환을 고려해야 함
• Rye가 목표로 했던 통합 Python 경험은 복잡한 프로젝트와 monorepo까지 포괄했지만, 유지관리 중심은 uv로 옮겨감

---

Rye의 현재 상태

• 개발 중단과 uv 권장

  • 모든 사용자에게 uv 사용이 권장됨
  • uv는 같은 유지관리자들이 만든 후속 프로젝트임
  • uv는 활발히 유지관리되고 있으며 Rye보다 훨씬 널리 사용됨
  • 기존 Rye 사용자는 uv migration guide를 참고할 수 있음
  • Rye는 계속 사용할 수 있지만, 추가 업데이트 계획이 없음
  • 보안 업데이트도 계획되어 있지 않음

Rye가 제공하던 기능

• Rye는 Python을 위한 프로젝트 및 패키지 관리 솔루션임
• Python 사용자를 위한 원스톱 도구를 목표로 만들어짐
• 하나의 통합 경험 안에서 다음 작업을 다룸
  • Python 설치 관리
  • pyproject.toml 기반 프로젝트 관리
  • 의존성 관리
  • virtualenv 관리
  • 전역 도구 설치
• 복잡한 프로젝트와 monorepo를 다룰 수 있도록 설계됨
• 소개 영상은 Watch an introduction에서 볼 수 있음

[lum7671]

저는 좀 됐지만, 이것 저것 사용하다가
Introduction - PDM
를 사용하고 있습니다.

Rye 도 사용을 해봐야 겠네요.

[GN⁺]

Hacker News 의견들

• 핵심 패키징 개발의 상당 부분이 이제 uv에서 진행 중이고, Rye는 내부적으로 uv를 사용하므로 uv가 좋아지면 Rye도 같이 좋아짐
  예를 들어 최근 uv에 범용 의존성 해석을 추가해서, 현재 실행 중인 시스템만이 아니라 모든 플랫폼과 운영체제에서 동작하는 단일 해석 결과로 잠긴 requirements.txt를 만들 수 있게 됐고, 최신 Rye도 이를 지원함
  https://github.com/astral-sh/uv
  Rye와 uv를 개발하고 있으니 질문이 있으면 답할 수 있음
  • Rye/UV의 범용 의존성 해석이 PyTorch에서도 제대로 동작하는지, 아니면 Poetry와 같은 문제를 겪는지 궁금함
    https://github.com/python-poetry/poetry/issues/6409
    https://news.ycombinator.com/item?id=39257501
  • 크로스 플랫폼 잠금 파일을 위한 작업이나 계획을 따라볼 수 있는지 궁금함
    내가 속한 팀이 옮기기 망설이는 이유 중 하나가 이 부분임. ML 작업을 하므로 PyTorch 기반 프로젝트를 예로 들면, 원하는 상태는 모든 의존성을 pyproject.toml에 두고 AArch64 Mac이나 AMD64 Windows 워크스테이션에서 다음 플랫폼 설정용 잠금 파일들을 생성할 수 있는 것임: 기본 MPS PyTorch를 쓰는 Mac, CUDA PyTorch를 쓰는 Windows, CPU PyTorch를 쓰는 AArch64 Linux, CPU PyTorch를 쓰는 AMD64 Linux, CUDA PyTorch를 쓰는 AMD64 Linux
    Ruff를 만들어줘서 고맙고, 린팅과 포매팅 모두 크게 만족하고 있음
  • 훌륭한 작업임. 예전에는 새 컴퓨터에서 프로젝트 작업 환경을 가끔 구성해야 했고 pyenv+venv+pip가 늘 고통스러웠는데, 이제는 Rye로 옮김
    지금은 Rye 설치, GitHub에서 가져오기, rye sync 입력이면 끝남
  • uv와 rye를 둘 다 맡고 있다면 왜 둘을 동시에 유지하는지 궁금함. 분열과 선택 부담에서 오는 혼란을 피하려면 지금 rye를 종료하는 편이 낫지 않나 싶음
  • 예측 가능하고 성능 좋은 빌드를 중요하게 여기는 회사들이 많이 넘어오고 있고, 그 과정에서 guac 같은 도구로 넣기 위한 SBOM 생성이 자주 필요해짐
    https://guac.sh/
    https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
    최근 추가된 의존성 고정 해제 기능 덕분에 개발 중에는 호환성을 유지하도록 유도하고, 재현성을 위해 정확하고 명시적인 requirements.txt를 생성할 수 있어 취약점 관리와 SBOM 단계가 Poetry 같은 도구보다 훨씬 쉬워짐
    비슷한 이유로 https://hatch.pypa.io/latest/why/를 쓰고 있고, uv와 잘 어울리는 점도 좋음
• Rye에서 꺼려졌던 점은 비표준 Python 빌드 사용을 강하게 권장한다는 부분임
  철학 페이지(https://rye.astral.sh/philosophy/)에서는 python.org의 CPython 빌드가 완전히 부적절하고, 플랫폼에 따라 .msi 설치 파일만 있거나 tarball만 있으며, 여러 Python 배포판이 크게 갈라져 하위 생태계에 온갖 문제를 만든다고 설명함. 그래서 이 프로젝트는 indygreg 독립 실행형 빌드를 쓰며, 언젠가 잘 관리되고 신뢰할 수 있는 Python 빌드가 나와 지금의 혼란을 대체하길 바란다고 함
  그 indygreg 빌드 정보는 https://gregoryszorc.com/docs/python-build-standalone/main/에 있고, 다른 Python을 선택하는 것도 가능함: https://rye.astral.sh/guide/toolchains/
  다만 나는 그들이 말하는 문제를 거의 겪어본 적이 없음. python.org에서 받은 공식 Python 빌드도 동작했고, 배포판 패키지 관리자로 설치한 평범한 Python도 동작했고, 공식 Docker 컨테이너 이미지에 포함된 Python도 동작했음
  그 특수 빌드들도 잘 동작하겠지만, 비표준성 때문에 망설여짐. 동작상의 특이점 목록까지 있는데, 문제가 없는 것에 왜 특이점을 추가하는지 모르겠음. Rye 철학이 그 빌드를 쓰는 데 너무 적극적인 것도, 운영체제에 이미 있는 Python을 기본으로 쓰는 대안들에 비해 매력을 떨어뜨림
  • 아마 이런 상황을 말하는 것 같음: 오래된 CentOS 같은 걸 쓰는 회사에서 일하고, 시스템 패키지 관리자는 Python 3.6보다 최신을 제공하지 않으며, python.org 공식 바이너리는 실행 시 glibc 버전에 관한 해독 불가 오류를 출력함
    소스에서 Python을 빌드하려면 새 시스템 의존성이 필요하고 오래 걸리며, 결국 누락된 헤더 파일에 대한 더 알 수 없는 오류가 나옴. 그 오류를 검색하면 업스트림 GCC가 2017년에 고친 문제를 우회하는 ./configure 플래그가 나오고, 어쨌든 성공은 함
    이런 3번 오류나 manylinux 빌드 환경을 겪어본 적이 없다면 고통의 세계를 통째로 피한 것임. Windows 설치 스크립팅이나 그 페이지의 “사용 가능한 CPU 명령어 제한” 같은 부분도 마찬가지임
  • Python 빌드, 패키징, 배포에는 두 극단이 있음. 하나는 왕도이고 다른 하나는 천 개의 칼날이 있는 복도임. 휴대용 Python 제안이 이해되지 않는다면 운이 좋았던 것이고, 계속 왕도에 머물렀다는 뜻임
  • Python 소스 코드를 정기적으로 내려받아 표준 프로덕션 최적화로 컴파일한 뒤 /use/local/python${version}에 설치하는데, Python 3.7이 나온 2018년 이후로 매우 일관되게 동작함
    내 경험상 이 명령들은 너무 안정적이고 일관적이라 자동화해도 될 정도임. 작성자가 문제 삼는 지점이나 근본적인 항의가 무엇인지 궁금함
  • “python.org의 CPython 빌드가 완전히 부적절하다”는 말은 아마 오래된 Python 버전의 보안 릴리스에 대해 macOS/Windows 바이너리가 없다는 뜻일 수 있음
    예를 들어 Python 3.10.14 설치 파일은 받을 수 없고, 마지막 Windows 설치 파일은 Python 3.10.11, 2023년 4월 5일 버전임
  • 동의함. PSF를 지원해야지 새로운 “올바른 방법”을 주장하는 건 이상한 입장임
• Rye를 좋아함. 표방한 일을 그대로 해내고, venv/Python 버전/패키징 전체 과정을 실제로 쾌적하게 만들며, pyproject.toml 같은 공식 Python 사용 방식에 익숙한 사람에게는 거의 투명하게 느껴짐
  게다가 Python을 Cargo처럼 느끼게 해주는데, Cargo도 쓰기 좋은 도구임
  • 나처럼 Poetry 류를 무시하고 pip-tools에 머물렀다면, Rye 내부에서 쓰는 uv는 그대로 대체 가능한 도구임
    개인적으로 pip-tools는 Poetry나 Pipenv보다 훨씬 나은 설계였다고 봄. pip와 virtualenv 양쪽에 직교적이었고, 둘 다 이미 Python에 오래 포함된 흐름이기 때문임. Rye는 반복 개선을 거친 표준 준수 접근이 이기는 모습이라고 볼 수 있음
    Rust 덕분의 속도 향상 외에도, 가상 환경을 어디에 둘지(.venv)와 여러 Python 버전을 어떻게 설치할지에 대해 적절한 기본값을 주는 점이 좋음. 작아 보이지만 wheel이 numpy 설치 문제를 해결한 뒤로는 이런 합리적 기본값과 내장 pip-tools가 사실상 빠진 전부였음. 그런 의미에서 바이너리 wheel이 생긴 뒤 Anaconda의 존재 이유가 무엇이었는지도 궁금함
  • Python은 모든 것에 한 가지 방법이 있다고 듣고 시작해봤는데, 설치와 환경 관리 경험은 난장판이었음
    이제라도 나아지고 있다니 반가움
  • “Python을 Cargo처럼 느끼게 한다”면 바로 설득됨. Poetry가 하루 종일 걸리고도 의존성을 해석하지 못해서 pixi를 써볼까 생각하던 중이었음
    Python 패키지 관리자가 Google 채팅 앱보다 더 많은 것 같음
  • “실제로 쾌적하게 만든다”는 게 무슨 뜻인지 궁금함. 너무 요약하기 어려운 건가? Anaconda나 Poetry에서 사용자 경험 측면으로 특별히 선택처럼 느껴졌던 부분을 잘 못 찾았음
    그리고 선별 측면에서는 더 크고 오래된 조직보다 작은 조직을 신뢰하라는 제안이 설득되기 어려워 보임. 즉 표방한 일이 정확히 무엇인지 궁금함. 내가 읽을 수 있는 건 “좋은 패키지 관리자는 좋고 빠르고 좋다” 정도라서, 비교나 철학 페이지가 있으면 좋겠음
• HN의 냉소가 가끔 놀라움
  Rye를 좋아함. Cargo나 Hex 같은 다른 언어의 패키지 관리자를 써본 뒤로 Python에도 비슷한 시스템이 없다는 점이 늘 아쉬웠는데, Rye가 그 갈증을 완전히 해결해줬음. venv, Python 버전, 프로젝트 의존성을 관리하려고 여러 도구를 설치하고 싶지 않은 입장에서는 Rye 하나로 모두 처리되는 게 정말 좋음
  • conda를 써봤는지 궁금함. conda와 비교하면 Rye가 어떤가?
    Rye는 아직 감이 없지만, conda도 venv, Python 버전, 프로젝트 의존성 관리를 잘 해낼 수 있음
  • 동의함. Rye는 나에게 잘 동작하고 있음. Python용 Cargo를 원했고, 지금까지 내 관점에서는 Rye가 그걸 달성했음
• 새 Python 의존성 관리자를 만나는 건 새 JavaScript 프레임워크를 우연히 발견하는 것 같음
  • 내 철학은 단순함. 배포 가능한 프로그램이어야 하면 그냥 Go를 쓰고, 포트 같은 게 필요 없으면 Docker를 쓰고, 조직에서 모두 쓰는 운영체제와 Python 버전이 설치된 컴퓨터를 IT팀이나 누군가가 건네준다면 venv를 쓰면 됨
    포트를 다뤄야 하거나, 프로그램을 배포해야 하거나, 라이브러리가 C나 운영체제 요소에 의존한다면, 돈을 받고 난 뒤 코드베이스를 관리할 필요도 없고 책임질 필요도 없는 컨설팅 일을 시작하는 편이 나음
  • 맞음. Docker는 10년 전쯤 이미 Python 프로그램 배포와 실행 문제를 해결했음
    요즘은 Docker에서 CUDA와 PyTorch도 실행할 수 있음. 이런 스레드에서 누군가 “그냥 Docker 쓰면 된다”고 하면 흔히 보이는 답은 “Docker를 배우고 싶지 않다”인데, Docker 경험이 전혀 없어도 Python 컨테이너를 띄우는 데 10분이면 됨
  • 맞음. 하지만 Poetry 같은 것들과 달리 이번 것은 실제로 좋음
  • 정말 심각함. 사용자 입장에서는 이렇게 여러 해가 지났는데도 표준이 없다는 게 답답함
• pixi(https://pixi.sh/latest/)가 좋음. Python 버전을 고정하고 conda와 PyPI에서 패키지를 설치할 수 있으며, Rust로 작성됨
  • 흥미로워 보이지만, 또 다른 생태계에 진지하게 투자하기는 어렵게 느껴짐. curl로 받아서 bash에 파이프하라고 하고, 이어서 임의 명령 출력에 eval하라고 하는 방식이 부담스러움
  • 링크 고마움. conda보다 빠른지 궁금함
  • pixi는 훌륭함. conda를 쓰는 사람이라면 pixi는 Git/프로젝트 디렉터리와 연결된 환경을 두는 conda 대체재로 쓸 수 있고, devbox/devenv/flox와 비슷함
    배경은 조금 복잡함. Anaconda 회사가 Python으로 작성한 conda가 있었고, 오픈소스 생태계인 conda-forge는 CI 빌드 봇을 갖춘 conda 채널임. 이후 같은 conda-forge 우산 아래에서 C++로 작성된 mamba가 conda의 대체재로 나왔고, 이건 alias conda=mamba가 동작해야 하는 수준의 실제 드롭인 대체재임. 지금은 conda도 속도를 높이기 위해 libmamba를 해석기로 사용함
    이후 mamba 작성자가 이를 pixi로 분리했고, Rust로 다시 작성하면서 환경 위치와 활성화 방식에 대한 철학을 바꿨지만 conda 환경과 완전 호환됨
    conda는 conda 채널에 없을 때 같은 경우 pip를 통해 PyPI 패키지 설치를 항상 지원했고, pixi는 uv를 통해 PyPI 패키지를 지원함. 그래서 pixi가 빠름. 블로그 글에 따르면 mamba보다도 훨씬 빠르게 만드는 다른 최적화도 있음
    순수 Python이 아닌 패키지를 쓴다면 conda 계열이 맞음. 패키지 관리자 선택(conda/mamba/pixi)은 부차적임
    PyPI의 문제는 문지기 역할이 부족하다는 점임. 여기에 순수 Python이 아닌 패키지를 표준적으로 패키징하는 방법이 부족한 문제가 겹쳐 환경이 새거나, 특히 소스만 배포하면서 setup.py에서 컴파일러까지 포함해 환경을 부트스트랩하는 이상한 일을 하면 재현 불가능해짐
    conda 쪽에서는 conda-forge 채널이 꽤 좋은 품질 관리를 함. 제약 조건, 라이선스, PyPI 배포본에 라이선스 파일이 빠지는 문제, 환경 격리 등을 확인함. 물론 잘못된 버전 제약을 가진 PyPI 변경을 자동 병합하는 공식 봇을 유지관리자가 쓸 수 있어서 완벽하진 않음
    지금 어떤 도구도 해결하지 못하는 문제는 PyPI 중심임. conda에 없는 패키지를 다뤄야 하고, 패키지 릴리스도 사실상 PyPI에 먼저 내는 것이 강제됨
    PyPI에만 있는 패키지를 conda를 통해 설치할 때도 그 의존성 중 일부는 conda에 있을 수 있음. 내가 알기로 PyPI 패키지 의존성을 충족하는 데 conda 패키지를 쓰는 패키지 관리자는 없음. 수동으로 conda 패키지를 추가해 의존성을 맞출 수는 있지만 올바른 버전 제약을 적용받지 못할 위험이 있음
    오픈소스 Python 패키지를 작성할 때도 설정이 conda 채널에만 의존하더라도 대부분 PyPI에 먼저 릴리스해야 하거나 그래야 함. conda-forge 채널 릴리스는 사실상 PyPI 존재를 요구하기 때문임. 그래서 나 같은 사람에게도 Rye는 여전히 유용할 수 있고 살펴볼 가치가 있음
• uv 쪽 사람들(https://astral.sh/blog/uv)이 이 Armin 프로젝트의 지휘봉을 넘겨받았다는 점은 알아둘 만함
• 소개 페이지에 “Rye is still a very experimental tool, but this guide is here to help you get started.”라고 되어 있음
  이 프로젝트가 매우 기대되지만, 더 성숙한 단계가 될 때까지 기다릴 계획임. Astral 팀이 내놓은 다른 것들을 모두 좋아해서 기대는 큼
• 우리는 openai-python 라이브러리 개발에 rye를 쓰고 있고, 아주 좋았음
• Rye는 좋아 보이고 Poetry도 꽤 즐겁게 썼지만, Go의 기본 도구 품질은 정말 존중하게 됨
  Python 프로젝트를 시작할 때마다 의존성/가상 환경 관리의 최신 상태를 다시 배워야 하는 느낌임