मुझे virtualenv और पाइप से नफरत क्यों है

मैं virtualenv (इसके बाद - venv) और पाइप के सार्वभौमिक प्रेम को साझा नहीं करता हूं। मेरा मानना ​​है कि वे केवल भ्रम पैदा करते हैं और इसके अलावा, वे नुकसान पहुंचाते हैं। पायथन प्रोग्रामर सबसे अधिक बार मुझसे असहमत होते हैं, और वेव + पाइप डे वास्तव में पायथन समुदाय में मानक माना जाता है। चूंकि मैं समझता हूं कि मेरे बयानों में कितना निराधार है, इसलिए मैंने इस ग्रंथ को लिखने का फैसला किया। बेशक, मैं वास्तविक जीवन में कभी-कभी इस विषय पर बहस करना शुरू कर देता हूं: ठीक है, मुझे लोगों को बनाना और यह देखना पसंद है कि वे कितनी लगन से अपनी स्थिति रखते हैं। लेकिन साथ ही, यह मुझे हमेशा लगता है कि मौखिक रूप से मैं अपनी स्थिति को पूरी तरह से सही नहीं ठहरा सकता। इसलिए, मौखिक रूप से अपनी बात साबित करने की लगातार कोशिश करने के बजाय, मैंने इस लेख को लिखने का फैसला किया, ताकि बाद में मैं इसे सिर्फ लोगों को दिखा सकूं। शायद तब कुछ मुझसे सहमत होंगे, क्योंकि अब लगभग कोई सहमत नहीं है। या शायद इसके विपरीत, जैसे ही मेरे तर्क पूरी तरह से समझ में आते हैं, ऐसे लोग होंगे जो उन्हें यथोचित रूप से खंडन करते हैं। एक तरह से या किसी अन्य, मुझे किसी भी परिदृश्य में खुशी होगी।

venv और अलगाव का भ्रम

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

पूर्ण अलगाव विधियां शिरा अतिरेक को जन्म देती हैं

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

venv एक परिनियोजन प्रतिमान है

एलएक्ससी जैसी प्रौद्योगिकियों का उल्लेख करते समय मैं कुछ पाठकों को परेशान करता हूं। हां, व्यवहार में, हम LXC के साथ हमेशा अपने लक्ष्य वातावरण की अनुकूलता सुनिश्चित नहीं कर सकते हैं। और हम हमेशा LXC को वह सुपर-एडमिन अधिकार नहीं दे सकते जिसकी उसे आवश्यकता है (और यह सब केवल हमारे आवेदन को तैनात करने के लिए है!)
लेकिन मेरा मानना ​​है कि वेव तैनाती के लिए भी उपयुक्त नहीं है। क्यों? जैसा कि शुरुआत में उल्लेख किया गया है, वेनव का प्रारंभिक उद्देश्य केवल अंतःक्रियात्मक रूप से निर्मित अजगर सैंडबॉक्स तक सुविधाजनक उपयोगकर्ता पहुंच प्रदान करना है। तैनाती कम से कम एक अर्ध-स्वचालित और आसानी से दोहराने योग्य प्रक्रिया है। इस प्रकार, वेनव को स्वचालित रूप से बनाने का प्रयास स्वचालित रूप से वह करता है जो मैन्युअल रूप से उस पर करने के लिए अधिक सुविधाजनक है, यह प्रोग्राम प्रविष्टि बिंदु के रूप में केवल PYTHONPATH पर्यावरण चर स्थापित करने की तुलना में अधिक जटिल और गैर-तुच्छ कार्य प्रतीत होता है। यह पाइप के माध्यम से स्थापित करने के लिए बहुत सरल है, जैसे Django, एक मनमाना फ़ोल्डर में (उपसर्ग विकल्प के माध्यम से)। कम से कम अप्रत्यक्ष रूप से वेनव को प्रबंधित करने और कई शेबंग के साथ भ्रमित होने की तुलना में बहुत आसान है। और यह मत भूलो कि वेनव के साथ, वास्तव में, आपके पास लक्षित वातावरण पर नियंत्रण नहीं है, और आपको विनम्रता से कंप्यूटर के व्यवस्थापक से पूछना होगा जिस पर आप क्लाइंट mysql पुस्तकालयों और हेडर फ़ाइलों को ऑपरेटिंग सिस्टम में स्थापित करने के लिए तैनात कर रहे हैं; यह सब इतना है कि आप बस तैनाती के लिए mysql-python संकलित कर सकते हैं!
वाणिज्यिक सॉफ्टवेयर वितरित करना आसान नहीं है, और वेव कोई मदद नहीं है।

venv बैसाखी से भरा है

जब आप venv स्थापित करते हैं, तो यह वास्तव में खाली नहीं होता है। पूरे मानक अजगर पुस्तकालय को lib / निर्देशिका में कॉपी किया जाता है। शामिल / / - अजगर हेडर फ़ाइलों का एक गुच्छा। इन निर्देशिकाओं के अस्तित्व का अर्थ मुझे (अगले पैराग्राफ में अधिक) लगता है, लेकिन बिन / मेरे लिए बहुत अधिक कष्टप्रद है। बिन में / पाइप और easy_install हैं। वेनव ने सिस्टम के तहत नहीं, बल्कि एक ही डायरेक्टरी में लेटे हुए अजगर दुभाषिया के नीचे उन्हें चलाने के लिए दोनों के चरवाहों को बिगाड़ दिया। अतिरिक्त रूप से स्थापित पैकेज से शेबबैंग और अन्य सभी स्क्रिप्ट बिल्कुल उसी तरह दूषित हो जाती हैं। और आपको वेनव के इस व्यवहार को बनाए रखना होगा और शेबन्स पर लगातार नज़र रखनी होगी, जबकि आपको वेव के अंदर पड़ी लिपियों के साथ "बाहर" काम करने की आवश्यकता है, उदाहरण के लिए, सिस्टम क्रोन के माध्यम से उन्हें चलाकर। आपको उपयुक्त वेनव के लिए मार्ग को हार्डकोड करना होगा ताकि स्क्रिप्ट सही दुभाषिया के नीचे चले। यह कम से कम थका हुआ है जैसा कि मैन्युअल रूप से PATH / PYTHONPATH को कॉन्फ़िगर करना है। वास्तव में, कुछ भी करना आसान है, लेकिन मैं थोड़ी देर बाद इस पर वापस आऊंगा।

ओह, मैं बिन / सक्रिय का उल्लेख करना भूल गया

जो PATH परिवेश चर सेट करता है और कंसोल में आपकी इनपुट लाइन बदलता है। यदि आपको हमेशा यह पसंद है, और आपको लगा कि यह उन्नत तकनीक है, तो ठीक है, बधाई हो, ऐसा लगता है कि आप एक टैंक में रहते थे। हालाँकि, आपकी स्क्रिप्ट की तरह। .NET विंडोज डेवलपर्स आप पर हंस रहे हैं।

--no-साइट-संकुल

vev दो तरह से sys.path को खराब करता है। Thesytem-site-package विकल्प मौजूदा मार्ग सूची के शीर्ष पर venv के साइट-पैकेज को संलग्न करता है, जिससे venv के अंदर विश्व स्तर पर स्थापित अजगर मॉड्यूल का उपयोग करना संभव हो जाता है। --No-site-package विकल्प भी है, जो डिफ़ॉल्ट रूप से सक्षम है, और जो, जैसा कि आप अनुमान लगा सकते हैं, यह संलग्नक नहीं है। जाहिरा तौर पर यही कारण है कि stdlib और हेडर फ़ाइलों जैसे कुछ पुस्तकालयों की प्रतियों को सही तरीके से वेनव के अंदर डाला जाता है। दरअसल, इस विकल्प के अस्तित्व का तथ्य, साथ ही साथ यह तथ्य कि यह डिफ़ॉल्ट रूप से सेट है, मेरी राय में, खुद के लिए बोलता है। जाहिर है, वेव प्रस्तावक सिस्टम और वेनव पर संकुल के बीच छिपी निर्भरता नहीं रखना चाहते हैं; चूंकि वे गलत संस्करणों के पैकेजों को गलती से वीवी में लीक नहीं करना चाहते हैं। हालांकि, उनका पसंदीदा वेव हमेशा रास्तों की सूची की शुरुआत में दिखाई देता है, इसलिए अभी भी एक छोटा सा मौका है (नहीं, मैं पाइप फ्रीज कमांड के बारे में नहीं भूलता हूं - हम इसके बारे में बाद में बात करेंगे)। यह डर अनावश्यक लग सकता है, लेकिन यहाँ विरोधाभास है। वास्तव में, venv ने कभी भी 100% अलगाव प्रदान नहीं किया है! यह क्या अच्छा है कि आप 100% सुनिश्चित हैं कि आप mysql-python के सिस्टम संस्करण का उपयोग नहीं कर रहे हैं, जबकि आप 100% सुनिश्चित हैं कि आप libmysqlclient के सिस्टम संस्करण का उपयोग कर रहे हैं! इन्सुलेशन का आंशिक रूप से उपयोग करना और इसे आंशिक रूप से अनदेखा करना असंभव है!

पाइप और वेनव एक शानदार गुच्छा है

हर कोई केवल इसलिए सोचता है क्योंकि वे एक ही व्यक्ति द्वारा लिखे गए हैं - इयान बेकिंग। दोनों कार्यक्रमों के अपने दर्शन और अपने स्वयं के उपयोग के मामले हैं। मुझे अधिकांश भाग के लिए वेनव पसंद नहीं है क्योंकि यह लोगों को विश्वास दिलाता है , लेकिन मैं मानता हूं कि इसका अपना स्थान है। वास्तव में, मैं स्वयं समय-समय पर त्वरित एक-बार परीक्षणों के लिए इसका उपयोग करता हूं। लेकिन दूसरी ओर, पाइप, बिल्कुल पैदा नहीं होना चाहिए था। यह अतिरिक्त घंटियों और सीटी के साथ easy_install के लिए एक "लगभग-संगत" विकल्प है जो बेहतर नहीं होगा। इसके बजाय, मैं easy_install का उपयोग करना पसंद करता हूं, इस तरह के इंटरैक्टिव के साथ मिलकर और कठपुतली या आमतौर पर स्रोत से संकुल संकलन जैसे कार्यक्रमों को नहीं। ऐसा लग सकता है कि मेरे पास पाइप के खिलाफ पूर्वाग्रह है, लेकिन ऐसा नहीं है। मैं मानता हूँ कि यह कंसोल में पाइप स्थापित करने के लिए easy_install की तुलना में कुछ अच्छा है। easy_install मूर्खतापूर्ण की तरह लगता है। और नाम में अंडरस्कोर स्पष्ट रूप से व्यावहारिक नहीं है। मैं शर्त लगाता हूं कि नाम ही इसकी कुछ लोकप्रियता के साथ पाइप प्रदान करता है।

पाइप हर बार स्रोत से बनाता है

अजगर में अंडे यह जावा में जार की तरह है

ऐसा लगता है कि बायनेरिज़ (अंडे) से पैकेज स्थापित करने के लिए पाइप जानबूझकर easy_install की क्षमता से वंचित था। इस तथ्य के बावजूद कि बायनेरिज़ का वितरण अजगर मंच का एक महत्वपूर्ण हिस्सा था और, वैसे, काफी कार्यात्मक, जाहिर है, किसी ने फैसला किया कि यह एक बुरा विचार था। बेशक, डेवलपर्स के दृष्टिकोण से, स्रोत से पैकेज संकलित करना एक स्पष्ट लाभ है, जो उन्हें सभी समर्थित प्लेटफार्मों में से प्रत्येक के लिए एक पैकेज को पूर्व-संकलित नहीं करने देता है (और इसे उपयोगकर्ता द्वारा इसे निस्संदेह रूप से हस्तांतरित करता है - लगभग।) । लेकिन अगर कुछ लक्ष्य प्लेटफ़ॉर्म हैं, तो संकलन बुरा हो जाता है, और आप निश्चित रूप से इसे जानते हैं / उन्हें चाहते हैं और पहले से ही पैकेज का निर्माण करना चाहते हैं, जिससे लक्ष्य कंप्यूटर पर एक कंपाइलर की आवश्यकता समाप्त हो जाती है (.NET और जावा डेवलपर्स फिर से आपकी समस्याओं पर हंसते हैं)। लेकिन सबसे बड़ी मूर्खतापूर्ण बात यह है कि यदि आप विकल्प -कोई-साइट-पैकेज के साथ वेनव का उपयोग करते हैं, तो हर बार आपकी टीम के प्रत्येक सदस्य, विकास प्रक्रिया के दौरान एसओई के अंदर वेनव को तैनात करते हुए, सभी मॉड्यूल को फिर से इकट्ठा करना होगा । और यह वास्तव में बेवकूफी है, क्योंकि आप उन्हें विकसित भी नहीं करते हैं और निरंतर आश्वस्तता में बस थोड़ी सी भी समझदारी नहीं है।

यह आवश्यकताओं

अपने पैकेज के लिए आवश्यक निर्भरताएं घोषित करने के लिए, आप उन्हें setup_requires में setup.py में निर्दिष्ट कर सकते हैं। यह अजगर का तरीका है। इस तंत्र को सेटअपटूल / वितरित करता है, और इसका उपयोग आसान_स्थापना और पाइप दोनों द्वारा किया जाता है, जो स्वचालित रूप से Pypi से डाउनलोड करता है और इन निर्भरताओं को स्थापित करता है। ऐसे कारणों के लिए जिन्हें समझाने में बहुत समय लगता है, पाइप आपको एक पाठ फ़ाइल में निर्भरता की एक सूची निर्दिष्ट करने देता है। इसे आमतौर पर आवश्यकताएँ कहा जाता है। इसका सिंटैक्स बिल्कुल सेटअप-थ्रू में जैसा है, लेकिन इसमें फ़ाइलों को अतिरिक्त रूप से संलग्न करने की क्षमता भी है जिसमें निर्भरता पथ को फ़ाइल पथ, URI और यहां तक ​​कि Mercurial- / Git रिपीटररी से लिंक के रूप में निर्दिष्ट किया जा सकता है (इस सब के बारे में हम अगले पैराग्राफ में बात करेंगे)।

मैं सहमत हूं कि ये कार्य संभावनाओं का विस्तार करते हैं, लेकिन मुझे विश्वास नहीं है कि वे आवश्यकताओं के अस्तित्व का कारण हैं। मेरी राय में, असली कारण यह है कि सभी पायथन परियोजनाओं को दो वर्गों में विभाजित किया गया है: पैकेज जो स्वतंत्र रूप से उपयोग नहीं किए जाते हैं और केवल मौजूदा परियोजनाओं में आयात किए जाते हैं और वास्तव में, ये परियोजनाएं स्वयं हैं। जो डेवलपर्स केवल एप्लिकेशन लिखते हैं, वे पैकेज बनाने की सभी विशेषताओं को पूरी तरह से नहीं समझते हैं, इसलिए, दो बार सोचने के बिना, वे बस अपने आवेदन में उपयोग किए जाने वाले मॉड्यूल की पूरी श्रृंखला "बस" करते हैं, बस उन्हें आवश्यकताओं में सूचीबद्ध करते हैं। क्योंकि यह बहुत सुविधाजनक है! ये डेवलपर्स सबसे अधिक बार उपयोगकर्ताओं को केवल वीवीवी स्थापित करने की सलाह देते हैं, और फिर अपने पैकेज को पाइप स्थापित -r आवश्यकताओं के साथ रोल करते हैं।

नतीजतन, हमारे पास कई अजगर डेवलपर्स हैं जो सभी समस्याओं के लिए आवश्यकताओं पर विचार करते हैं। वे सेटपूल के अस्तित्व के बारे में भी कभी नहीं जान पाएंगे। वे आसानी से इंटरनेट के आंत्रों में कहीं न कहीं पड़े हुए आवश्यक पैकेजों के लिए लिंक के प्रतीत होने वाले सरल बेवकूफी से मोहित हो जाते हैं: साइटों पर या संस्करण नियंत्रण प्रणालियों में। मैं इस दृष्टिकोण के "शानदार" व्यावहारिकता में उनके पवित्र आत्मविश्वास से हतोत्साहित हूं और हर किसी के लिए अपरिहार्य उपकरणों के एक बंडल के रूप में virtualenv + पाइप के उपयोग को बढ़ावा देने की इच्छा है।

यूआरआई निर्भरता पथ के रूप में बेकार है

setuptools आपको नाम और पैकेज के आवश्यक संस्करण को निर्दिष्ट करने की अनुमति देता है, जिसे डिफ़ॉल्ट रूप से Pypi से डाउनलोड किया जाता है। Pypi अनुक्रमण प्रदान करता है, लेकिन आप अपना खुद का सूचकांक (साधारण HTML पृष्ठों के रूप में) बना सकते हैं और संकेत कर सकते हैं कि जानकारी मुख्य रूप से उनसे निकाली जानी चाहिए, न कि Pypi वेबसाइट से। जिसने भी इस तकनीक को विकसित किया है, उसने डेवलपर को अपने भौतिक स्थान या वेब प्रोटोकॉल को नहीं, बल्कि नामों को बांधने की क्षमता प्रदान करने की कोशिश की। और उसने सही तरीके से सोचा।

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

खैर, एक और तरीका है। इस तरह से निर्भरताएँ निर्दिष्ट करते हैं:
git + https: //github.org/my/stupid/fucking/package#egg=1.2.2

लेकिन इसके लिए उपयोगकर्ता को कंप्यूटर पर गिट की आवश्यकता होती है, इसके अलावा, पाइप को रिपॉजिटरी की एक पूरी प्रति को पंप करना पड़ता है। और अधिक बार, लोग वर्जन नोटेशन का उपयोग बिल्कुल नहीं करते हैं (उदाहरण में लगभग 1.2.3 - प्रति।)। और मान लें कि स्थिर संस्करण मास्टर शाखा में झूठ होना चाहिए। यह सब दुखद है। मुझे पता है कि संस्करण नियंत्रण प्रणालियों से सीधे सब कुछ डालने के लिए यह फैशनेबल है, लेकिन आपकी परियोजना में इन यूआरएल को "कट्टर" कहा जाता है? एक पहले से ही विवादास्पद निर्णय, जो पूरी तरह से अनुचित हो जाता है, अगर सब कुछ सही ढंग से किया जा सकता है, तो उचित setup.py सेटअप पर बस थोड़ा पसीना।

यदि आप पाइप फ्रीज पसंद करते हैं, तो आपके साथ कुछ गलत है

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

दूसरी ओर, यह पता लगाने पर कि इन निर्भरताओं ने आपके पर्यावरण को बर्बाद कर दिया है, आप बस इसे फिर से बनाने की कोशिश कर सकते हैं। लेकिन वेनव + पाइप के साथ यह आपको हमेशा के लिए ले जाएगा (मैं आपको याद दिलाता हूं, आपको सब कुछ और सब कुछ पुनर्निर्माण करने की आवश्यकता होगी)। जबकि LXC CoW के साथ और पहले से ही बाइनरी अंडे पैकेज में पैक किया गया है (सभी निर्भरताएं जो आप इस समय काम नहीं कर रहे हैं), आप बहुत तेज़ी से लापता निर्भरता पाएंगे - सिस्टम स्तर पर और सीधे अजगर में।
सामान्य तौर पर, पाइप फ्रीज़ इतनी खराब टीम नहीं है, बात यह है कि बहुत बार लोग इसे अपूरणीय मानते हैं, इसकी कमियों को ध्यान में नहीं रखते हैं और इसका उपयोग अन्य उद्देश्यों के लिए करते हैं।

निष्कर्ष

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

अनुवादक से:
विंडोज पर काम करने वाले डेवलपर्स के लिए: चाहे आप पाइप को छोड़ने का फैसला करते हैं या सिर्फ कुछ पैकेजों को स्थापित करने का एक तरीका ढूंढ रहे हैं, जो तुरंत पाइप करना नहीं चाहते हैं (उदाहरण के लिए, जो vcvarsall.bat को खोजने में असमर्थ त्रुटि के साथ गिर रहे हैं), और पैकेज डेवलपर्स की साइटों पर संकलित। संस्करण प्रदान नहीं किए गए हैं, मैं एक अद्भुत साइट को इसके विंग के तहत सभी संभावित संस्करणों में सभी प्रकार के संकलित पैकेजों को इकट्ठा करने की सलाह दे सकता हूं: पायथन एक्सटेंशन पैकेजों के लिए अनौपचारिक विंडोज बायनेरिज़