Rye: बिना झंझट वाला Python अनुभव

• Rye एक project और package management tool था, जिसका उद्देश्य Python installation, pyproject.toml projects, dependencies, virtualenv, और global tool installation को एक ही जगह संभालना था
• फिलहाल इसका development बंद हो चुका है, और उन्हीं maintainers द्वारा बनाए गए follow-up project uv का उपयोग करने की सलाह दी जाती है
• मौजूदा users uv migration guide देखकर migrate कर सकते हैं, और Rye अभी भी डाउनलोड किया जा सकता है, लेकिन आगे कोई update planned नहीं है
• updates बंद होने में security updates भी शामिल हैं, इसलिए नए projects या long-term maintenance environments में uv पर switch करने पर विचार करना चाहिए
• Rye जिस integrated Python experience को लक्ष्य बना रहा था, उसमें complex projects और monorepo तक शामिल थे, लेकिन maintenance का focus uv पर शिफ्ट हो गया है

---

Rye की वर्तमान स्थिति

• development बंद और uv की सिफारिश

  • सभी users को uv इस्तेमाल करने की सलाह दी जाती है
  • uv उन्हीं maintainers द्वारा बनाया गया follow-up project है
  • uv actively maintained है और Rye की तुलना में कहीं अधिक व्यापक रूप से इस्तेमाल होता है
  • मौजूदा Rye users uv migration guide देख सकते हैं
  • Rye का उपयोग जारी रखा जा सकता है, लेकिन आगे कोई additional updates planned नहीं हैं
  • security updates भी planned नहीं हैं

Rye द्वारा दी जाने वाली सुविधाएँ

• Rye Python के लिए एक project और package management solution था
• इसे Python users के लिए one-stop tool बनाने के लक्ष्य से बनाया गया था
• एक unified experience के भीतर यह निम्न काम संभालता था
  • Python installation management
  • pyproject.toml आधारित project management
  • dependency management
  • virtualenv management
  • global tool installation
• इसे complex projects और monorepo को संभालने के लिए design किया गया था
• introduction video Watch an introduction पर देखा जा सकता है

[lum7671]

मुझे थोड़ा समय हो गया है, लेकिन यह-वह आज़माने के बाद
Introduction - PDM
का उपयोग कर रहा हूँ।

लगता है Rye भी इस्तेमाल करके देखना चाहिए।

[GN⁺]

Hacker News की राय

• core packaging development का काफ़ी हिस्सा अब uv में हो रहा है, और क्योंकि Rye अंदरूनी रूप से uv का उपयोग करता है, इसलिए uv बेहतर होता है तो Rye भी साथ में बेहतर होता है
  उदाहरण के लिए, हाल ही में uv में universal dependency resolution जोड़ा गया है, जिससे एक single resolution result के साथ locked requirements.txt बनाया जा सकता है जो सिर्फ़ अभी चल रहे system के लिए नहीं बल्कि सभी platforms और operating systems पर काम करता है, और नवीनतम Rye भी इसे support करता है
  https://github.com/astral-sh/uv
  मैं Rye और uv दोनों पर काम कर रहा हूँ, इसलिए कोई सवाल हो तो जवाब दे सकता हूँ

  • जानना चाहता हूँ कि क्या Rye/UV का universal dependency resolution PyTorch के साथ भी ठीक से काम करता है, या फिर इसे Poetry जैसी समस्याएँ आती हैं
    https://github.com/python-poetry/poetry/issues/6409
    https://news.ycombinator.com/item?id=39257501
  • जानना चाहता हूँ कि cross-platform lock files के लिए हो रहे काम या योजनाओं को कहीं follow किया जा सकता है या नहीं
    मेरी टीम के हिचकिचाने की एक वजह यही है। हम ML काम करते हैं, तो PyTorch-आधारित project का उदाहरण लें तो हमारी ideal स्थिति यह होगी कि सभी dependencies pyproject.toml में रहें और AArch64 Mac या AMD64 Windows workstation से इन platform configurations के लिए lock files generate किए जा सकें: default MPS PyTorch वाला Mac, CUDA PyTorch वाला Windows, CPU PyTorch वाला AArch64 Linux, CPU PyTorch वाला AMD64 Linux, CUDA PyTorch वाला AMD64 Linux
    Ruff बनाने के लिए धन्यवाद, linting और formatting दोनों से बहुत संतुष्ट हूँ
  • शानदार काम। पहले कभी-कभी नए computer पर project work environment सेटअप करना पड़ता था और pyenv+venv+pip हमेशा दर्दनाक था, लेकिन अब Rye पर आ गया हूँ
    अब बस Rye install करो, GitHub से pull करो, rye sync चलाओ और काम हो गया
  • अगर आप uv और rye दोनों देख रहे हैं तो दोनों को एक साथ maintain करने की वजह क्या है, यह जानना चाहता हूँ। fragmentation और choice overload से आने वाली उलझन से बचने के लिए क्या इस समय rye को बंद कर देना बेहतर नहीं होगा?
  • predictable और high-performance builds को महत्व देने वाली बहुत-सी कंपनियाँ migrate कर रही हैं, और उस प्रक्रिया में guac जैसे tools में डालने के लिए SBOM generation की ज़रूरत अक्सर पड़ती है
    https://guac.sh/
    https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python
    हाल ही में जोड़ी गई dependency unpinning capability की वजह से development के दौरान compatibility बनाए रखने की दिशा मिलती है, और reproducibility के लिए सटीक और explicit requirements.txt generate किया जा सकता है, इसलिए vulnerability management और SBOM चरण Poetry जैसे tools की तुलना में काफ़ी आसान हो जाते हैं
    इसी तरह की वजहों से मैं https://hatch.pypa.io/latest/why/ का उपयोग कर रहा हूँ, और यह भी अच्छा लगता है कि यह uv के साथ अच्छी तरह फिट बैठता है

• Rye को लेकर मेरी झिझक की वजह यह है कि यह non-standard Python builds के उपयोग को बहुत मज़बूती से recommend करता है
  philosophy page(https://rye.astral.sh/philosophy/) में कहा गया है कि python.org के CPython builds पूरी तरह उपयुक्त नहीं हैं; platform के हिसाब से कहीं सिर्फ़ .msi installer मिलता है या कहीं सिर्फ़ tarball, और कई Python distributions काफ़ी बिखरे हुए हैं, जिससे नीचे के ecosystem में तरह-तरह की समस्याएँ पैदा होती हैं। इसलिए यह project indygreg standalone builds का उपयोग करता है, और उम्मीद करता है कि कभी कोई अच्छी तरह maintained और भरोसेमंद Python build आए जो आज की इस अव्यवस्था को बदल दे
  उन indygreg builds की जानकारी यहाँ है: https://gregoryszorc.com/docs/python-build-standalone/main/ और दूसरा Python चुनना भी संभव है: https://rye.astral.sh/guide/toolchains/
  लेकिन मुझे उन्होंने जिन समस्याओं का ज़िक्र किया है, उनका लगभग कभी सामना नहीं करना पड़ा। python.org से मिला official Python build भी चला, distro package manager से install किया हुआ सामान्य Python भी चला, और official Docker container image में शामिल Python भी चला
  वे खास builds भी शायद ठीक चलते होंगे, लेकिन उनकी non-standard nature की वजह से हिचक होती है। उनके behavior differences की सूची तक है, इसलिए समझ नहीं आता कि जो चीज़ बिना समस्या के चल रही है उसमें अलग तरह की विशेषताएँ क्यों जोड़ी जाएँ। Rye philosophy का उन builds को लेकर इतना आक्रामक होना भी, operating system में पहले से मौजूद Python को default मानने वाले alternatives की तुलना में, इसकी appeal कम कर देता है

  • शायद मतलब ऐसी स्थितियों से है: आप किसी ऐसी कंपनी में काम करते हैं जो पुराना CentOS चलाती है, system package manager Python 3.6 से नया कुछ नहीं देता, और python.org का official binary चलाने पर glibc version के बारे में अपठनीय error देता है
    source से Python build करने के लिए नए system dependencies चाहिए, बहुत समय लगता है, और अंत में missing header files के बारे में कोई और भी कम समझ आने वाला error मिलता है। उस error को search करने पर ./configure flags मिलते हैं जो upstream GCC द्वारा 2017 में ठीक की गई समस्या के workaround होते हैं, और किसी तरह अंत में build सफल हो जाता है
    अगर आपने यह तीसरे तरह की error या manylinux build environments नहीं झेले हैं, तो आपने सचमुच एक पूरी पीड़ादायक दुनिया से बचाव किया है। Windows install scripting या उस page पर “usable CPU instructions limiting” जैसी बातें भी इसी तरह की हैं
  • Python build, packaging और distribution में दो चरम स्थितियाँ हैं। एक है royal road, और दूसरी है हज़ार ब्लेड वाला गलियारा। अगर portable Python का प्रस्ताव आपको समझ नहीं आता, तो इसका मतलब है कि आप भाग्यशाली रहे हैं और लगातार उसी royal road पर चलते रहे हैं

• Python source code को नियमित रूप से डाउनलोड करके standard production optimization के साथ compile किया जाता है और फिर /use/local/python${version} में install किया जाता है, और यह Python 3.7 के 2018 में आने के बाद से बहुत लगातार काम कर रहा है
  मेरे अनुभव में ये commands इतनी स्थिर और consistent हैं कि इन्हें automate भी किया जा सकता है। लेखक को असल में किस बात से समस्या है या उनकी बुनियादी आपत्ति क्या है, यह जानने की उत्सुकता है

  • “python.org के CPython builds पूरी तरह अनुपयुक्त हैं” का मतलब शायद यह हो सकता है कि पुराने Python versions के security releases के लिए macOS/Windows binaries उपलब्ध नहीं हैं
    उदाहरण के लिए Python 3.10.14 installer डाउनलोड नहीं किया जा सकता, और आख़िरी Windows installer Python 3.10.11 है, जो 5 अप्रैल 2023 का version है
  • सहमत हूँ। PSF को support करना चाहिए; कोई नया “सही तरीका” बताना एक अजीब रुख़ लगता है

• मुझे Rye पसंद है। यह जो करने का दावा करता है, वही करता है, और venv/Python version/packaging की पूरी प्रक्रिया को सच में सहज बना देता है, जबकि pyproject.toml जैसी आधिकारिक Python usage style से परिचित लोगों के लिए यह लगभग पारदर्शी लगता है
  साथ ही, यह Python को Cargo जैसा महसूस कराता है, और Cargo भी इस्तेमाल करने के लिए एक अच्छा tool है

  • अगर मेरी तरह आपने Poetry जैसी चीज़ों को नज़रअंदाज़ करके pip-tools पर ही टिके रहे हैं, तो Rye के अंदर इस्तेमाल होने वाला uv एक पूरी तरह बदलने योग्य tool है
    व्यक्तिगत रूप से मुझे लगता है कि pip-tools, Poetry या Pipenv से कहीं बेहतर design था। यह pip और virtualenv दोनों के प्रति orthogonal था, और दोनों ही पहले से Python में लंबे समय से मौजूद flow का हिस्सा थे। Rye को इस रूप में देखा जा सकता है कि standards-compliant, iterative सुधार वाला approach जीत रहा है
    Rust की वजह से मिलने वाली speed improvements के अलावा, virtual environment कहाँ रखना है (.venv) और कई Python versions कैसे install करने हैं, इस पर यह अच्छे defaults देता है। यह छोटी बात लग सकती है, लेकिन wheel के numpy install समस्याएँ हल करने के बाद से ऐसे sensible defaults और built-in pip-tools ही लगभग आख़िरी कमी थे। इसी अर्थ में, binary wheel आने के बाद Anaconda के अस्तित्व का कारण क्या रह गया, यह भी सोचने वाली बात है
  • मैंने यह सोचकर Python शुरू किया था कि हर चीज़ का एक ही तरीका होगा, लेकिन installation और environment management का अनुभव पूरी तरह बिखरा हुआ था
    अब यह बेहतर हो रहा है, यह देखकर अच्छा लगता है
  • अगर यह “Python को Cargo जैसा महसूस कराता है”, तो मैं तुरंत तैयार हूँ। Poetry पूरा दिन लेकर भी dependencies resolve नहीं कर पाया, इसलिए मैं pixi आज़माने के बारे में सोच रहा था
    लगता है Python package managers की संख्या Google chat apps से भी ज़्यादा है
  • “वास्तव में सहज बनाता है” से आपका क्या मतलब है, यह जानना चाहूँगा। क्या इसे बहुत संक्षेप में बताना मुश्किल है? Anaconda या Poetry में user experience के लिहाज़ से मुझे कोई ऐसी खास चीज़ नहीं मिली जो अलग चयन जैसी लगे
    और चयन के लिहाज़ से, बड़े और पुराने संगठनों की बजाय छोटे संगठनों पर भरोसा करने का सुझाव बहुत persuasive नहीं लगता। यानी यह ठीक-ठीक क्या करने का दावा करता है, यह जानना चाहता हूँ। मुझे जो पढ़ने को मिलता है वह बस “अच्छा package manager अच्छा, तेज़ और अच्छा है” जैसा लगता है, इसलिए कोई comparison या philosophy page हो तो अच्छा होगा

• HN का cynicism कभी-कभी चौंकाता है
  मुझे Rye पसंद है। Cargo या Hex जैसे दूसरी languages के package managers इस्तेमाल करने के बाद मुझे हमेशा यह कमी खलती थी कि Python में वैसा system नहीं है, और Rye ने उस कमी को पूरी तरह भर दिया। अगर आप venv, Python version, और project dependencies manage करने के लिए कई tools install नहीं करना चाहते, तो Rye एक ही tool में सब कुछ दे देता है, जो बहुत अच्छा है

  • क्या आपने conda इस्तेमाल किया है? conda की तुलना में Rye कैसा है?
    Rye का मुझे अभी अंदाज़ा नहीं है, लेकिन conda भी venv, Python version, और project dependency management अच्छे से कर सकता है
  • सहमत हूँ। Rye मेरे लिए अच्छी तरह काम कर रहा है। मुझे Python के लिए Cargo चाहिए था, और अभी तक मेरी नज़र में Rye ने वही दिया है

• किसी नए Python dependency manager से मिलना ऐसा लगता है जैसे कोई नया JavaScript framework अचानक दिख जाए

  • मेरी philosophy सरल है। अगर यह deploy किया जा सकने वाला program होना चाहिए, तो बस Go इस्तेमाल करो; अगर ports जैसी किसी चीज़ की ज़रूरत नहीं है, तो Docker इस्तेमाल करो; और अगर IT team या कोई और आपको ऐसा computer दे दे जिसमें organization का standard OS और Python version पहले से installed हो, तो venv इस्तेमाल कर लो
    अगर ports संभालने हैं, या program deploy करना है, या library C या OS components पर निर्भर है, तो बेहतर है कि पैसे मिलने के बाद codebase को maintain करने या उसकी ज़िम्मेदारी लेने की आवश्यकता न हो, और सीधे consulting का काम शुरू कर दिया जाए
  • सही कहा। Docker ने लगभग 10 साल पहले ही Python programs को deploy और run करने की समस्या हल कर दी थी
    आजकल Docker में CUDA और PyTorch भी चल सकते हैं। ऐसे threads में जब कोई कहता है “बस Docker इस्तेमाल करो”, तो आम जवाब होता है “मैं Docker सीखना नहीं चाहता”, लेकिन Docker का बिल्कुल भी अनुभव न हो तब भी Python container चलाने में 10 मिनट लगते हैं
  • सही है। लेकिन Poetry जैसी चीज़ों के विपरीत, यह वाला सच में अच्छा है
  • यह सच में गंभीर बात है। user के नज़रिए से इतने सालों बाद भी कोई standard न होना परेशान करने वाला है

• pixi(https://pixi.sh/latest/) अच्छा है। यह Python version को pin कर सकता है, conda और PyPI से packages install कर सकता है, और Rust में लिखा गया है

  • दिलचस्प लगता है, लेकिन किसी और ecosystem में गंभीरता से निवेश करना मुश्किल महसूस होता है। curl से लेकर bash में pipe करने को कहना, और फिर किसी arbitrary command output पर eval चलाने को कहना, थोड़ा बोझिल लगता है
  • लिंक के लिए धन्यवाद। जानना चाहूँगा कि क्या यह conda से तेज़ है
  • pixi शानदार है। अगर आप conda इस्तेमाल करते हैं, तो pixi को Git/project directory से जुड़ा environment रखने वाले conda replacement की तरह इस्तेमाल कर सकते हैं, और यह devbox/devenv/flox जैसा है
    इसका background थोड़ा जटिल है। Anaconda कंपनी के पास Python में लिखा हुआ conda था, और open source ecosystem conda-forge, CI build bots वाला एक conda channel है। बाद में उसी conda-forge umbrella के तहत C++ में लिखा mamba, conda के replacement के रूप में आया, और यह इतना वास्तविक drop-in replacement है कि alias conda=mamba काम करना चाहिए। अब conda भी speed बढ़ाने के लिए libmamba को solver के रूप में इस्तेमाल करता है
    इसके बाद mamba के लेखक ने इसे pixi के रूप में अलग किया, Rust में दोबारा लिखा, और environment location व activation method को लेकर philosophy बदल दी, लेकिन यह conda environments के साथ पूरी तरह compatible है

conda ने conda चैनल में उपलब्ध न होने पर भी हमेशा pip के जरिए PyPI पैकेज इंस्टॉल करने का समर्थन किया है, और pixi, uv के जरिए PyPI पैकेजों को सपोर्ट करता है। इसलिए pixi तेज़ है। ब्लॉग पोस्ट के अनुसार mamba से भी कहीं ज़्यादा तेज़ बनाने वाली अन्य optimizations भी हैं
अगर आप शुद्ध Python नहीं, ऐसे पैकेज इस्तेमाल करते हैं, तो conda परिवार सही विकल्प है। पैकेज मैनेजर का चयन (conda/mamba/pixi) द्वितीयक है
PyPI की समस्या यह है कि वहाँ gatekeeper की भूमिका कमज़ोर है। इसके साथ शुद्ध Python न होने वाले पैकेजों को standard तरीके से पैकेज करने की कमी भी जुड़ जाती है, जिससे environment leak हो सकता है, और खासकर जब केवल source distribute किया जाए और setup.py में compiler तक शामिल करके environment को bootstrap करने जैसी अजीब चीज़ें की जाएँ, तो reproducibility खत्म हो जाती है
conda पक्ष में conda-forge चैनल काफ़ी अच्छा quality control करता है। यह constraints, license, PyPI distribution में license file छूट जाने की समस्या, environment isolation आदि की जाँच करता है। बेशक, यह पूरी तरह perfect नहीं है, क्योंकि maintainers एक आधिकारिक bot का इस्तेमाल कर सकते हैं जो गलत version constraints वाले PyPI बदलावों को auto-merge कर देता है
अभी वह समस्या जिसे कोई भी tool हल नहीं कर पाया है, PyPI-केंद्रित है। conda में न होने वाले पैकेजों को संभालना पड़ता है, और पैकेज रिलीज़ भी व्यवहार में पहले PyPI पर ही डालना लगभग अनिवार्य है
PyPI-only पैकेजों को conda के जरिए इंस्टॉल करते समय भी उनकी कुछ dependencies conda में हो सकती हैं। मेरी जानकारी में ऐसा कोई पैकेज मैनेजर नहीं है जो PyPI पैकेज dependencies को पूरा करने के लिए conda पैकेजों का इस्तेमाल करता हो। आप मैन्युअली conda पैकेज जोड़कर dependencies पूरी कर सकते हैं, लेकिन सही version constraints लागू न होने का जोखिम रहता है
open source Python पैकेज लिखते समय भी, भले ही configuration केवल 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.”
  मुझे इस प्रोजेक्ट से बहुत उम्मीद है, लेकिन मैं इसके और mature stage में पहुँचने तक इंतज़ार करने की योजना बना रहा हूँ। Astral टीम की बाकी चीज़ें भी मुझे बहुत पसंद आई हैं, इसलिए उम्मीद बड़ी है
• हम openai-python लाइब्रेरी के विकास में rye का इस्तेमाल कर रहे हैं, और अनुभव बहुत अच्छा रहा
• Rye अच्छा लगता है और Poetry का इस्तेमाल भी काफ़ी आनंददायक रहा, लेकिन Go के default tools की quality वाकई सम्मान जगाती है
  हर बार Python प्रोजेक्ट शुरू करते समय ऐसा लगता है जैसे dependency/virtual environment management की मौजूदा स्थिति फिर से सीखनी पड़ती है