पहियों पर अजगर

पायथन के लिए पैकेज सिस्टम बुनियादी ढांचे की लंबे समय से डेवलपर्स और सिस्टम प्रशासक दोनों द्वारा आलोचना की गई है। लंबे समय तक, यहां तक ​​कि समुदाय स्वयं भी सहमत नहीं हो सके कि प्रत्येक विशेष मामले में किस उपकरण का उपयोग किया जाए। डिस्टुटिल्स, सेटपूल, डिस्ट्रीब्यूट, डिस्टुटिल्स 2 पहले से ही बुनियादी वितरण तंत्र के रूप में मौजूद हैं, और इस सारे गड़बड़ को प्रबंधित करने के लिए वर्चुअलबेन, बिल्डआउट, ईजी-इंस्टॉलेशन और उच्च-स्तरीय टूल के रूप में पाइप।

सेटप्टूल से पहले, मुख्य वितरण प्रारूप विंडोज के लिए स्रोत फाइलें या कुछ बाइनरी एमएसआई वितरण थे। लिनक्स के तहत, bdist_dumb और bdist_rpm शुरू में टूट गए थे, जो केवल Red Hat आधारित सिस्टम पर काम करता था। लेकिन यहां तक ​​कि bdist_rpm ने लोगों को इसका उपयोग शुरू करने के लिए पर्याप्त रूप से काम नहीं किया।

कुछ साल पहले, PJE ने डिस्टल्यूट में सुधार लाने और मेटाडेटा को पायथन पैकेज में जोड़ने के लिए सेटप्टूल और pkg_resource का मिश्रण प्रदान करके इस समस्या को ठीक करने का प्रयास किया। इसके अलावा, उन्होंने उन्हें स्थापित करने के लिए easy_install उपयोगिता लिखी। मेटाडेटा का समर्थन करने वाले वितरण प्रारूप की कमी के कारण, 'अंडा' प्रारूप प्रदान किया गया था।

अजगर अंडे नियमित रूप से जिप अभिलेखागार होते हैं जिसमें एक अजगर पैकेज और आवश्यक मेटाडेटा होते हैं। हालांकि बहुत से लोग शायद जानबूझकर अंडे एकत्र नहीं करते हैं, उनका मेटाडेटा प्रारूप अभी भी जीवित है और अच्छी तरह से है। और हर कोई अपनी परियोजनाओं को सेटपूल के उपयोग से तैनात कर रहा है।

दुर्भाग्य से, कुछ समय बाद, समुदाय अलग हो गया, और इसका हिस्सा विशेष रूप से द्विआधारी प्रारूप और 'अंडे' की मृत्यु की घोषणा की। उसके बाद, पाइप, easy_install की जगह, अंडे के प्रारूप को स्वीकार करना बंद कर दिया।

फिर थोड़ा और समय बीत गया, और बाइनरी पैकेजों की अस्वीकृति से असुविधा होने लगी। लोगों ने अधिक से अधिक क्लाउड सर्वर को तैनात करना शुरू कर दिया, और प्रत्येक मशीन पर सी-शनी पुस्तकालयों को फिर से स्थापित करने की आवश्यकता बहुत प्रसन्न नहीं है। चूंकि उस समय 'अंडे' अस्पष्ट थे (मुझे ऐसा लगता है), उन्हें नए पीईपी में फिर से बनाया गया था, और उन्हें ' पहिये ' कहा जाता था।

यह माना जाता है कि सभी क्रिया एक आभासी वातावरण में होती हैं ।

किस तरह का पहिया?

चलो एक साधारण से शुरू करते हैं। 'पहिये' क्या हैं और वे 'अंडे' से कैसे भिन्न हैं? दोनों प्रारूप ज़िप फाइलें हैं। मुख्य अंतर यह है कि अंडे को अनपैकिंग के बिना आयात किया जा सकता है, जबकि पहिया को अनपैक करना होगा। हालाँकि पहियों को गैर-आयात करने के लिए कोई तकनीकी कारण नहीं हैं, फिर भी उनके सीधे आयात के लिए समर्थन की योजना नहीं बनाई गई है।

एक और अंतर यह है कि 'अंडे' में संकलित बायटेकोड होते हैं, जबकि 'पहिये' नहीं होते। इसका मुख्य लाभ यह है कि पायथन के प्रत्येक संस्करण के लिए अलग-अलग पहियों को बनाने की आवश्यकता नहीं है, जब तक कि आपको लिबासथॉन के माध्यम से जुड़े मॉड्यूल को वितरित नहीं करना है। हालांकि पाइथन 3 के नए संस्करणों में, स्थिर एबीआई का उपयोग करते हुए, यहां तक ​​कि यह पहले से ही क्रैंक किया जा सकता है।

हालांकि, पहिया प्रारूप भी समस्याओं के बिना नहीं है, जिनमें से कुछ यह 'अंडे' से विरासत में मिला है। उदाहरण के लिए, लिनक्स के तहत द्विआधारी वितरण अभी भी दो कमियों के कारण अधिकांश के लिए अस्वीकार्य है: पायथन स्वयं लिनक्स के तहत विभिन्न रूपों में संकलित करता है, और मॉड्यूल अलग-अलग सिस्टम लाइब्रेरी से लिंक करते हैं। पहली समस्या अजगर 2: USC2 और USC4 के असंगत संस्करणों के सह-अस्तित्व के कारण होती है। संकलन मोड के आधार पर एबीआई बदलता है। वर्तमान में, पहिया (जहां तक ​​मैं बता सकता हूं) में ऐसी जानकारी नहीं है जिसके बारे में यूनिकोड मोड पुस्तकालय से जुड़ा है। एक अलग समस्या यह है कि लिनक्स वितरण हम चाहते हैं की तुलना में एक दूसरे के साथ कम संगत हैं, और परिस्थितियां उत्पन्न हो सकती हैं ताकि एक वितरण के लिए संकलित असेंबली दूसरों पर काम न करे।

यह सब इस तथ्य में तब्दील हो जाता है कि, आम तौर पर बोलते हुए, बाइनरी 'व्हील्स' को विभिन्न प्रणालियों के साथ असंगत के रूप में PyPI पर अपलोड नहीं किया जा सकता है।

इन सब के अलावा, पहिया अब केवल दो चरम सीमाओं को जानता है: बाइनरी पैकेज और पैकेज जिसमें प्योर पाइथन कोड होता है। बाइनरी पैकेज पायथन शाखा के लिए विशिष्ट हैं 2. x। अब यह एक बड़ी समस्या नहीं लगती है, क्योंकि 2.x चक्र समाप्त हो रहा है, और केवल 2.7 के लिए एकत्र किए गए पैकेज लंबे समय तक पर्याप्त होंगे। लेकिन अगर यह अचानक अजगर 2.8 पर आ गया, तो यह कहना दिलचस्प होगा कि यह पैकेज पायथन के संस्करण पर निर्भर नहीं करता है, लेकिन इसमें बायनेरिज़ शामिल है, इसलिए यह आर्किटेक्चर पर निर्भर नहीं कर सकता है।

इस तरह के पैकेज के अस्तित्व को सही ठहराने वाला एकमात्र मामला तब है जब इसमें CFFI से ctypes के साथ भरी हुई लाइब्रेरी शामिल हैं। इस तरह के पुस्तकालयों को लिबेपीथॉन के माध्यम से नहीं जोड़ा जाता है और वे भाषा के कार्यान्वयन से स्वतंत्र होते हैं (उनका उपयोग pypy के साथ भी किया जा सकता है)।

लेकिन एक उज्ज्वल पक्ष है: कुछ भी अपने स्वयं के सजातीय अवसंरचना में बाइनरी पहियों के उपयोग पर प्रतिबंध नहीं लगाता है।

व्हील असेंबली

तो अब हम जानते हैं कि पहिया क्या है। अपना 'पहिया' कैसे बनाएं? अपने स्वयं के पुस्तकालयों से इकट्ठा करना सबसे सरल प्रक्रिया है। आपको बस setuptools और wheel लाइब्रेरी का नवीनतम संस्करण चाहिए। एक बार दोनों स्थापित हो जाने के बाद, 'पहिया' को निम्न कमांड के साथ इकट्ठा किया जाता है:

 $ python setup.py bdist_wheel 

पैकेज निर्देशिका में पहिया बनाया जाएगा। हालाँकि, एक चीज़ से सावधान रहना चाहिए: बायनेरिज़ का वितरण। डिफ़ॉल्ट रूप से, इकट्ठे 'पहिया' (यह मानते हुए कि सेटअप में कोई बाइनरी स्टेप्स का उपयोग नहीं किया जाता है) में शुद्ध-पायथन कोड होता है। इसका मतलब यह है कि भले ही आप .so , .dylib या .dll को अपने पैकेज के हिस्से के रूप में वितरित करते हैं, जिसके परिणामस्वरूप 'व्हील' प्लेटफॉर्म-स्वतंत्र दिखाई देगा।

इस समस्या का समाधान मैन्युअल रूप से सेटपूल से वितरण को लागू करना है, पवित्रता के झंडे को फेंकना है:

 import os from setuptools import setup from setuptools.dist import Distribution class BinaryDistribution(Distribution): def is_pure(self): return False setup( ..., include_package_data=True, distclass=BinaryDistribution, ) 

व्हील सेटिंग

पाइप के नवीनतम संस्करण का उपयोग करते हुए, 'पहिया' निम्नानुसार सेट किया गया है:

 $ pip install package-1.0-cp27-none-macosx_10_7_intel.whl 

लेकिन निर्भरता के बारे में क्या? कुछ कठिनाइयाँ हैं। आमतौर पर एक पैकेज के लिए आवश्यकताओं में से एक इंटरनेट कनेक्शन के बिना भी इसे स्थापित करने की क्षमता है। सौभाग्य से, पाइप आपको इंडेक्स से लोडिंग को अक्षम करने और एक निर्देशिका स्थापित करने की अनुमति देता है जिसमें सब कुछ है जिसे आपको स्थापित करने की आवश्यकता है। यदि हमारे पास आवश्यक संस्करणों के सभी निर्भरता के लिए पहिए हैं, तो आप निम्न कार्य कर सकते हैं:

 $ pip install --no-index --find-links=path/to/wheels package==1.0 

यह हमारे वर्चुअल वातावरण में पैकेज package संस्करण 1.0 को स्थापित करेगा।

व्यसनों के लिए पहिए

ठीक है, लेकिन क्या होगा यदि हमारे पास हमारी सभी निर्भरता नहीं है। सिद्धांत में पिप आपको wheel कमांड का उपयोग करके इस समस्या को हल करने की अनुमति देता है। यह कुछ इस तरह काम करना चाहिए:

 pip wheel --wheel-dir=path/to/wheels package==1.0 

यह कमांड उन सभी पैकेजों को अनलोड करेगा, जिन पर हमारा पैकेज निर्दिष्ट फ़ोल्डर पर निर्भर करता है। लेकिन कुछ समस्याएं हैं।
पहला यह है कि वर्तमान में टीम के पास एक बग है जो निर्भरता को अनलोड नहीं करता है जो पहले से ही 'पहिए' हैं। इसलिए यदि पहिया प्रारूप में PyPI पर निर्भरता पहले से ही उपलब्ध है, तो इसे लोड नहीं किया जाएगा।

यह अस्थायी रूप से एक शेल स्क्रिप्ट द्वारा हल किया जाता है जो कैश से मैन्युअल रूप से डाउनलोड किए गए पहियों को स्थानांतरित करता है।

 #!/bin/sh WHEEL_DIR=path/to/wheels DOWNLOAD_CACHE_DIR=path/to/cache rm -rf $DOWNLOAD_CACHE_DIR mkdir -p $DOWNLOAD_CACHE_DIR pip wheel --use-wheel -w "$WHEEL_DIR" -f "$WHEEL_DIR" \ --download-cache "$DOWNLOAD_CACHE_DIR" package==1.0 for x in "$DOWNLOAD_CACHE_DIR/"*.whl; do mv "$x" "$WHEEL_DIR/${x##*%2F}" done 

दूसरी समस्या थोड़ी और गंभीर है: अगर पाईपीआई पर नहीं है तो पाइप हमारे अपने पैकेज को कैसे खोजेगा? यह सही है, कुछ भी नहीं। इस मामले में, प्रलेखन pip wheel package का उपयोग नहीं करने की सलाह देता है, लेकिन pip wheel -r requirements.txt , जहां requirements.txt । सभी आवश्यक निर्भरताएं शामिल हैं।

DevPI का उपयोग करके बिल्डिंग पैकेज

निर्भरता समस्या का इस तरह का एक अस्थायी समाधान सरल स्थितियों में काफी लागू होता है, लेकिन क्या होगा यदि कई आंतरिक अजगर पैकेज हैं जो एक दूसरे पर निर्भर हैं? यह डिजाइन जल्दी टूट जाता है।

सौभाग्य से, पिछले साल होलकर ट्रेकेल ने देवपीआई नामक इस आपदा का हल बनाया, जो अनिवार्य रूप से एक हैक है जो PyPI के साथ पाइप कार्य का अनुकरण करता है। एक बार कंप्यूटर पर स्थापित होने के बाद, DevPI PyPI से पहले एक पारदर्शी प्रॉक्सी के रूप में कार्य करता है और पाइप को स्थानीय रिपॉजिटरी से पैकेज स्थापित करने की अनुमति देता है। इसके अलावा, PyPI से डाउनलोड किए गए सभी पैकेज स्वचालित रूप से कैश हो जाते हैं, इसलिए यदि आप नेटवर्क को डिस्कनेक्ट करते हैं, तो भी ये पैकेज इंस्टॉलेशन के लिए उपलब्ध होंगे। और, अंत में, अपने स्वयं के संकुल को स्थानीय सर्वर में अपलोड करना संभव हो जाता है ताकि उन्हें उसी तरह से संदर्भित किया जा सके जैसे कि सार्वजनिक सूचकांक में संग्रहीत किया जाता है।

मैं स्थानीय virtualenv में DevPI स्थापित करने की सलाह देता हूं, जिसके बाद PATH में devpi-server और devpi लिंक जोड़ते हैं।

 $ virtualenv devpi-venv $ devpi-venv/bin/pip install --upgrade pip wheel setuptools devpi $ ln -s `pwd`/devpi-venv/bin/devpi ~/.local/bin $ ln -s `pwd`/devpi-venv/bin/devpi-server ~/.local/bin 

उसके बाद, यह सिर्फ devpi-server को शुरू करने के लिए बना हुआ devpi-server , और यह तब तक काम करेगा जब तक कि इसे मैन्युअल रूप से बंद नहीं किया जाता है।

 $ devpi-server --start 

इसे शुरू करने के बाद, आपको इसे एक बार शुरू करने की आवश्यकता है:

 $ devpi use http://localhost:3141 $ devpi user -c $USER password= $ devpi login $USER --password= $ devpi index -c yourproject 

चूंकि मैं DevPI 'का उपयोग अपने लिए करता हूं', DevPI उपयोगकर्ता नाम और सिस्टम उपयोगकर्ता नाम समान हैं। अंतिम चरण में, परियोजना के नाम से एक सूचकांक बनाया जाता है (यदि आवश्यक हो, तो आप कई बना सकते हैं)।

स्थानीय भंडार में पाइप को पुनर्निर्देशित करने के लिए, आप पर्यावरण चर का निर्यात कर सकते हैं:

 $ export PIP_INDEX_URL=http://localhost:3141/$USER/yourproject/+simple/ 

मैं इस आदेश को गलत अनुक्रमित से आकस्मिक लोडिंग को रोकने के लिए अपने virtualenv के postactivate स्क्रिप्ट में postactivate ।

स्थानीय DevPI में अपने स्वयं के पहिये लगाने के लिए, devpi उपयोगिता का devpi :

 $ devpi use yourproject $ devpi upload --no-vcs --formats=bdist_wheel 

--no-vcs जादू को निष्क्रिय करता है जो एक संस्करण नियंत्रण प्रणाली की पहचान करने का प्रयास करता है और कुछ फ़ाइलों को पहले स्थान पर ले जाता है। मुझे इसकी आवश्यकता नहीं है, क्योंकि मेरी परियोजनाओं में फाइलें वितरित की जाती हैं, जिन्हें मैं वीसीएस (बायनेरिज़, उदाहरण के लिए) में शामिल नहीं करता।

अंत में, मैं अत्यधिक सेटअप सेटअप फ़ाइलों को इस तरह से विभाजित करने की सलाह देता हूं कि PyPI उन्हें अस्वीकार कर देता है, और DevPI स्वीकार करता है ताकि गलती से setup.py resease कोड के साथ अपने कोड को ओवरलोड न करें। ऐसा करने का सबसे आसान तरीका एक गलत PyPI क्लासिफायर जोड़ना है:

 setup( ... classifier=['Private :: Do Not Upload'], ) 

लपेट लो

अब सब कुछ आंतरिक निर्भरता का उपयोग शुरू करने और अपने स्वयं के 'पहियों' को इकट्ठा करने के लिए तैयार है। जैसे ही वे दिखाई देते हैं, उन्हें संग्रहीत किया जा सकता है, दूसरे सर्वर पर डाउनलोड किया जा सकता है और एक अलग वर्चुअनव में स्थापित किया जा सकता है।
पूरी प्रक्रिया थोड़ी आसान हो जाएगी जब pip wheel मौजूदा पहिया पैकेजों को अनदेखा करना बंद कर देगा। इस बीच, ऊपर शेल स्क्रिप्ट सबसे खराब समाधान नहीं है।

'अंडे' की तुलना में

अब पहिया प्रारूप अंडे की तुलना में अधिक आकर्षक है। इसका विकास अधिक सक्रिय है, PyPI ने अपना समर्थन जोड़ना शुरू कर दिया है और, क्योंकि उपयोगिताएं इसके साथ काम करना शुरू कर देती हैं, यह सबसे अच्छा समाधान की तरह दिखता है। 'अंडे' अब तक केवल easy_install द्वारा समर्थित हैं, हालांकि अधिकांश ने पाइप पर स्विच किया है।

मेरा मानना ​​है कि ज़ोप समुदाय अभी भी सबसे बड़ा अंडा आधारित और बिल्डआउट आधारित समुदाय है। और मेरा मानना ​​है कि यदि आपके मामले में 'अंडे' पर आधारित समाधान लागू है, तो इसे लागू किया जाना चाहिए। मुझे पता है कि बहुत से अंडे का उपयोग नहीं करते हैं, वे वर्चुअन बनाने के लिए पसंद करते हैं, उन्हें संग्रहित करते हैं और उन्हें विभिन्न सर्वरों को भेजते हैं। बस इस तरह की तैनाती के लिए, पहियों का सबसे अच्छा समाधान है, क्योंकि विभिन्न सर्वरों में अलग-अलग पुस्तकालय पथ हो सकते हैं। एक समस्या थी कि .pyc लिए एक बिल्ड सर्वर पर .pyc फाइलें बनाई जाती थीं, और इन फाइलों में विशिष्ट फ़ाइल पथ होते हैं। पहिया .pyc का उपयोग आभासी वातावरण में स्थापना के बाद बनाया जाता है और स्वचालित रूप से सही रास्ते होंगे।

तो अब आपके पास है। पहियों पर अजगर। और यह भी काम करता है, और शायद खर्च किए गए समय के लायक है।