PYX: Python पैकेजिंग का अगला चरण
(astral.sh)- pyx uv डेवलपमेंट टीम द्वारा बनाया गया एक Python native package registry है, जो PyPI, PyTorch और private sources से इंस्टॉल की गति को अधिकतम 10 गुना तक बढ़ाता है
- पारंपरिक package registry की सीमा से आगे बढ़कर, यह speed, security और GPU awareness जैसी क्षमताएँ देता है, और internal packages के साथ-साथ PyPI, PyTorch जैसे public sources को भी सपोर्ट करता है
- package popularity, creation time और vulnerability status जैसे मानदंडों के आधार पर फ़िल्टर किए जा सकने वाले dedicated index URL प्रदान करता है, जिससे security और compliance मजबूत होते हैं
- Python के लिए विशेष रूप से बने modern standards support और uv के साथ direct integration के जरिए बिना किसी configuration के authentication और उपयोग संभव है
- टीम के भीतर duplicate builds, PyTorch·CUDA इंस्टॉलेशन की जटिलता, build breakage और authentication की असुविधा जैसी enterprise environment की प्रमुख समस्याओं को server-client integration से हल करता है
- GPU awareness के जरिए हार्डवेयर के अनुसार PyTorch, vLLM, FlashAttention, DeepSpeed आदि के prebuilt versions को consistent metadata और optimal configuration के साथ उपलब्ध कराता है
- optimized artifacts और uv native metadata API के जरिए अन्य private registries की तुलना में कहीं बेहतर performance देता है
Astral की दृष्टि और पृष्ठभूमि
- Astral Python ecosystem के लिए high-performance developer tools बनाने वाली कंपनी है, और Ruff (linter·formatter) तथा uv (package manager) के लिए अच्छी तरह जानी जाती है
- इसकी स्थापना का कारण यह एहसास था कि Python दुनिया की सबसे लोकप्रिय programming language होने के बावजूद tooling के स्तर पर पर्याप्त समर्थन नहीं पा रही थी
- फिलहाल Astral toolchain में हर महीने 10 करोड़ से अधिक installs होते हैं, और uv प्रतिदिन 50 करोड़ से अधिक requests संभाल रहा है, यानी इसकी वृद्धि बेहद तेज़ है
- लक्ष्य Python को सबसे productive programming ecosystem बनाना है, और इसके लिए client tools से आगे बढ़कर Python cloud बनाना चाहती है
pyx परिचय
- pyx uv के optimized backend के रूप में डिज़ाइन किया गया एक Python native package registry है
- internal packages को host कर सकता है
- PyPI और PyTorch index जैसे public sources के लिए accelerated और configurable frontend की भूमिका निभाता है
- मुख्य विशेषताएँ
- तेज़ इंस्टॉलेशन गति : package installation और build optimization
- PyPI, PyTorch और internal private sources से package install करते समय optimized artifacts और uv native metadata API का उपयोग
- अन्य private registries की तुलना में अधिकतम 10 गुना तेज़
- security और compliance में सुधार : dependencies और supply chain की समझ के जरिए जोखिम को कम करना
- package filtering के लिए dedicated index URL बनाए जा सकते हैं
- popularity, release age और vulnerability status जैसे मानदंडों के आधार पर package access control
- server side पर reproducible builds सुनिश्चित करना
- modern standards support
- Python के लिए विशेष नवीन packaging standards और workflows को सपोर्ट करता है
- uv के साथ direct integration होने से अलग configuration के बिना सहज authentication और उपयोग संभव
- GPU-aware package distribution : CUDA और PyTorch से जुड़े builds और deployment को सरल बनाना
- PyTorch, vLLM, FlashAttention, DeepSpeed जैसी GPU-संबंधित libraries के लिए customized prebuilt packages उपलब्ध
- hardware-based optimal configuration और consistent metadata बनाए रखता है
- तेज़ इंस्टॉलेशन गति : package installation और build optimization
जिन समस्याओं को हल करना है
- PyTorch, CUDA, FlashAttention, DeepSpeed जैसी GPU-संबंधित libraries को इंस्टॉल करने की कठिनाई
- टीम के भीतर एक ही package के बार-बार build होने से resources की बर्बादी
- setuptools update के कारण build errors
- internal registry authentication process की असुविधा
server-client integration रणनीति
- uv (client) और pyx (server) का vertical integration ऊपर की समस्याओं को सीधे हल करता है
- pyx के बिना केवल uv, या uv के बिना केवल pyx का उपयोग संभव है, लेकिन साथ में उपयोग करने पर सर्वोत्तम अनुभव मिलता है
- open source tools के साथ गहरे integration के जरिए ऐसा developer experience संभव होता है जो पहले संभव नहीं था
business model
- uv, Ruff, ty आदि Astral tools हमेशा के लिए free, open source और permissive license के तहत रहेंगे
- इसके बदले pyx जैसी paid hosted services देकर “अगले चरण” की infrastructure demand को पूरा किया जाएगा
वर्तमान स्थिति और आगे की योजना
- फिलहाल Ramp, Intercom, fal जैसे early partners के साथ संचालन में है
- GA (general availability) से पहले open build के जरिए तेज़ feedback loop बनाए रखा जाएगा
- रुचि रखने वाली टीमों और प्रशंसकों से संपर्क करने का अनुरोध
4 टिप्पणियां
मैं यह सोचते हुए पढ़ता गया कि यह कंपनी पैसा कैसे कमाती होगी, और फिर पता चला कि वे
pyxको paid तौर पर देने की योजना बना रहे हैं।यह कहना कि All python packaging challenges are solved काफ़ी हास्यास्पद है।
यह हल नहीं हुआ है, बस किसी तरह चल जाए इतना करके किनारे रख दिया गया है, है ना, हा हा
Python दुनिया भर में इस्तेमाल होने वाली एक मुख्यधारा की भाषा है, लेकिन इसका environment बहुत ही बिखरा हुआ है, यह सच है।
Hacker News की टिप्पणियों में लोग इस बात पर चिंता करते हैं कि 'कंपनियाँ' आगे आ रही हैं, लेकिन वे यह नहीं सोचते कि जब तक कंपनियाँ आगे नहीं आईं, तब तक किसी ने इस पर ध्यान ही नहीं दिया, और इसी वजह से स्थिति ऐसी हो गई।
FYI: Hacker News की टिप्पणियों में किसी ने जो कहा था, उसका उद्धरण
Hacker News की राय
शायद इससे ज़्यादा उपयोगी ब्लॉग पोस्ट शेयर कर रहा हूँ https://astral.sh/blog/introducing-pyx
मुझे लगता है Python packaging की सारी समस्याएँ पहले ही हल हो चुकी हैं। यहाँ सीखा गया सबक यह है कि हर समस्या के लिए एक ही परफेक्ट solution नहीं होता। VC फंडिंग वाली कंपनियों से ज़्यादा जुड़ना या उनके infrastructure पर निर्भर होना FOSS community के लिए हमेशा बड़ा risk है
मैंने pip इस्तेमाल करने की सलाह सुनकर शुरुआत की थी। लेकिन वह धीमा था और अक्सर दिक्कतें आती थीं। इसलिए virtualenv पर गया, लेकिन उसने समस्या का सिर्फ एक हिस्सा हल किया। उसके बाद conda इस्तेमाल किया, जो कभी-कभी ठीक चला, लेकिन मेरे shell profile का हाल खराब कर दिया और अक्सर package version उलझ जाते थे। फिर pipenv की सिफारिश मिली, शुरुआत में अच्छा लगा, लेकिन development ठप पड़ गया, लोग बदल गए, और बाद के versions में वह बार-बार टूटता रहा। फिर poetry सुझाया गया, लेकिन वह इतना धीमा था कि इस्तेमाल नहीं कर पाया। इसलिए वापस pip और built-in venv पर लौटा, लेकिन पहले वाली समस्याएँ फिर से सामने आ गईं, और features भी कम थे। फिर uv पर गया, और वह कम से कम ठीक से काम करता था। लेकिन जिन dependencies की मुझे ज़रूरत है, उनका build और packaging OS और GPU के हिसाब से बदल जाता है, इसलिए मेरे सहकर्मी इस project को अपने laptop पर install तक नहीं कर पाते। अच्छा है कि Python packaging की सारी समस्याएँ "हल" हो चुकी हैं
"Python packaging की सारी समस्याएँ पहले ही हल हो चुकी हैं" कहना सच कहूँ तो या तो बिना जानकारी के है या अज्ञानता का नतीजा है। Python के पास अभी भी अलग-अलग platforms पर native dependencies को भरोसेमंद तरीके से संभालने का तरीका नहीं है। pip और setuptools को इस ecosystem की अंतिम सीमा नहीं होना चाहिए
मैं इस चिंता से सहमत हूँ, लेकिन uv इस्तेमाल करने के बाद मैंने इतना समय बचाया है कि जब तक VC capital की बुराइयाँ इसे पूरी तरह बर्बाद नहीं कर देतीं, तब तक मैं इसे इस्तेमाल करता रहूँगा। तब तक उम्मीद है community किसी एक दिशा में इकट्ठा हो जाएगी
पिछले 3 घंटों से python और debian को भिड़ाकर काम कराने की कोशिश कर रहा था और Python ecosystem पर गुस्सा चढ़ गया। कुछ भी हल नहीं हुआ है। Debian में सिर्फ venv के इस्तेमाल की सलाह दी जाती है, लेकिन venv में install किए गए packages को cmake जैसे tools अक्सर ढूँढ नहीं पाते। apt-get packages भी हैं, कुछ tools सिर्फ वही ढूँढते हैं और कुछ उन्हें भी नहीं ढूँढ पाते। package names भी एकसमान नहीं हैं। मेरे console ने pipx सुझाया, लेकिन अनुभव लगभग वैसा ही रहा। ऊपर से पुराने python 2 vs 3 के अवशेष अब भी बचे हुए हैं, इसलिए version number शामिल है या नहीं, इस वजह से package discovery अक्सर fail हो जाती है। मुझे c++headerparser क्या है यह भी न पता हो, फिर भी आखिर में यही यक़ीन हो जाता है कि Python को build tree से निकालकर इतिहास में दफना देना ही सही होगा
क्या आप यहाँ नए हैं? आइए, यह Kool Aid एक बार पीकर देखिए। गिलास पर लगा "MongoDB" logo नज़रअंदाज़ कर सकते हैं। वह पुरानी चीज़ है
open source products पर कई बार भरोसा करके चोट खा चुका हूँ। ऐसे वादे अनगिनत बार सुन चुका हूँ। कभी न कभी acquisition हो जाता है, और वर्षों से जमा docs, issues, और PR लगभग बिना चेतावनी साफ कर दिए जाते हैं। फिर नई कंपनी कोई commercial product निकालती है, लेकिन उसमें वे core features भी नहीं होते जो मैं इस्तेमाल करता था
मैं इस चिंता को समझता हूँ, फिर भी यह ज़ोर देकर कहना चाहूँगा कि pyx, Astral के मौजूदा tools से अलग एक रणनीतिक रूप से अलग किया गया product है। आधिकारिक घोषणा में भी कहा गया है, "pyx Astral की strategy का साकार रूप है, और Astral के tools आगे भी हमेशा free, open source, और बहुत permissive license के साथ रहेंगे।" हमारा लक्ष्य open source tools को monetize करने के बजाय एक अलग commercially sustainable product बनाकर चिंताओं को कम करना है
यह चिंता पूरी तरह समझ में आती है। फिर भी मुझे लगता है कि Astral की reputation और track record सचमुच शानदार हैं। HN पर इतनी सतर्क प्रतिक्रिया देखकर हैरानी हुई। 10 साल से ज़्यादा समय से Python development कर रहा हूँ, और Astral कुछ भी करे तो मुझमें उत्साह पैदा होता है
अगर यह सचमुच valuable feature होता, तो शायद pip में merge कर दिया गया होता
PyTorch, CUDA, या FlashAttention, DeepSpeed जैसी चीज़ें install करना मुश्किल है—इस बात से पूरी तरह सहमत हूँ। Windows (और WSL) में कुछ packages बहुत पुराने Visual Studio compiler versions माँगते हैं, इसलिए manually download path ढूँढना भी झंझट बन जाता है। बेहतर developer experience का इंतज़ार है
असल में WSL लगभग Linux जैसा ही है, इसलिए मुझे नहीं लगता कि Visual Studio compiler version इतना मायने रखता है। WSL binaries सब Linux toolchain से build होती हैं। Windows में भी libc, Win10 के बाद से काफ़ी stable है। VC++ 2015 या उसके बाद से build किए गए binaries के बीच C-ABI compatibility बनी रहती है। सिर्फ़ कुछ अपवादों में पुराना compiler चाहिए होता है—जैसे जब कोई खास language feature पुराने compiler में supported न हो, या C++ objects को सीधे ABI boundaries के पार भेजना हो। ऐसे cases बहुत कम हैं
ऐसे ही episodes की वजह से मैंने Rails के कारण Ruby को पूरी तरह छोड़ दिया था। Ruby के videos देखो तो सब लोग मज़े से development करते दिखते हैं, तो थोड़ी ईर्ष्या होती थी, लेकिन मेरे environment में dev environment set up करने के लिए DigitalOcean droplet लेना पड़ता था, और अक्सर Rails compile errors से सब गड़बड़ा जाता था। 2012 के आसपास Rails boom में शामिल होना चाहता था, लेकिन setup/install process हमेशा दुःस्वप्न जैसा था। इसलिए Python पर आ गया, शुरू में ठीक था, लेकिन आजकल AI या CUDA से जुड़ा कुछ हो तो installation hell की वजह से यह तक लगता है कि किसी और की shell script follow करना ही बेहतर है
GPU-केंद्रित workflows में Python packaging को इसी दिशा में जाना चाहिए। खासकर दो चीज़ों का इंतज़ार है। पहली, accelerator-specific (जैसे CUDA/ROCm/CPU अलग-अलग) compatibility-validated indexes मिलें, ताकि torch/cu* matrix वाली बहस खत्म हो। दूसरी, metadata को client query कर सके ताकि installs parallelize किए जा सकें। अगर pyx ML environments में होने वाले इस ‘pip trial-and-error loop’ को कम कर दे, और hardware-targeted builds तथा predictable hashes भी दे, तो environment setup में लगने वाला बहुत समय बचेगा। साथ ही tool को open source रखना और hosting service से revenue कमाने वाला model trust बनाने के लिए अच्छा है। यह भी जिज्ञासा है कि pyx dependency graph, reverse dependencies (अगर X→Y हो तो क्या टूटेगा?), और SBOM/signing attestations जैसे supply-chain checks भी support करेगा या नहीं
एक समय था जब operating system में compiler built-in होना सामान्य बात मानी जाती थी
पहले मैंने anaconda अपनाने का निर्णायक कारण यही environment था
मज़ाक में कहा गया कि "जल्द ही Python packaging के 14 competing standards हो जाएँगे।" सच तो यह है कि 14 तो मज़ाक है, इससे भी ज़्यादा हुए काफी समय हो चुका है
मुझे लगता है Python packaging, Python की सबसे कम Zen वाली चीज़ है
पिछले साल सितंबर में Charlie ने Mastodon पर बताया था कि वह इस business model पर विचार कर रहा है https://hachyderm.io/@charliermarsh/113103564055291456
मैं जानना चाहता हूँ कि GPU-aware registry से ठोस रूप में क्या मतलब है। क्या uv मेरे GPU specs देखकर, उसके मुताबिक packages का set Pyx से अपने-आप चुनकर ला सकता है? अगर यह enterprise customers के लिए private, paid registry है, तो क्या कोई कंपनी ऐसी registry को public instance के रूप में बाहर भी दे सकती है? यानी अगर मैं vendor हूँ, तो क्या मैं अपने packages के लिए paid Pyx registry चला सकता हूँ और उसे अपने customers के लिए entrypoint की तरह इस्तेमाल कर सकता हूँ?
uv pip install --torch-backend=auto torchचलाने पर, यह PyTorch index से मेरे GPU के लिए सही PyTorch version अपने-आप install कर देता है। pyx इस model को और आगे बढ़ाता है। सिर्फ़ PyTorch ही नहीं, बल्कि हर hardware accelerator के लिए curated indexes होते हैं, और इन indexes में अलग-अलग packages, versions, Python versions, PyTorch versions आदि के built artifacts consistent metadata के साथ तैयार रहते हैं। यानी pyx इस्तेमाल करने पर compatibility/speed के हिसाब से सही builds आसानी से मिल सकते हैं, और uv client भी उपयुक्त pyx index अपने-आप ढूँढ सकता है (यह हिस्सा pyx हो या न हो, बुनियादी रूप से implement किया जा सकता है, लेकिन pyx के साथ यह कहीं ज़्यादा शक्तिशाली हो जाता है)। साथ ही, vendors अपनी packages के लिए खुद pyx-style registry चलाकर उसे customers के entrypoint की तरह दें—यह अभी आधिकारिक रूप से supported नहीं है, लेकिन अगर इसमें ठोस रुचि हो तो संपर्क करके चर्चा की जा सकती हैमैंने कुछ हफ़्ते पहले भी कहा था, Astral कभी न कभी monetization strategy लाएगा। मेरा अनुमान है कि उसका केंद्र Uv नहीं, बल्कि protected private PyPI जैसी कोई चीज़ होगी https://news.ycombinator.com/item?id=44712558
मुझे समझ नहीं आ रहा कि इस बात का point क्या है। असल में Charlie Marsh ने पिछले साल सितंबर में खुद यही समझाया था—enterprise के लिए private package registry जैसी चीज़ एक strategic example हो सकती है (ज़रूरी नहीं कि वही अंतिम रूप हो, लेकिन strategy को ठोस रूप देने का उदाहरण था)। Astral अपने business model को लेकर काफ़ी transparent है https://hachyderm.io/@charliermarsh/113103605702842937
“monetization” शब्द नकारात्मक लग सकता है, लेकिन इन्होंने सचमुच बेहतरीन tools बनाए हैं, इसलिए जो companies चाहती हैं कि ये लोग और भी समस्याएँ हल करें, वे खुशी से इसके लिए पैसे देंगी
मैंने अभी तक uv adopt नहीं किया है, और देख रहा हूँ कि आगे यह किस दिशा में जाता है। हाल में Anaconda tools की उपयोगिता को भी license बदलावों की वजह से फिर से परखना पड़ा था, और Qt के साथ भी ऐसा ही हुआ। एक और licensing problem का सामना करने का विचार ही भारी लगता है