स्थानीय सोर्स आर्काइव को फिर भी नेटवर्क एक्सेस की आवश्यकता हो सकती है। pip उसे इंस्टॉल कर सके, इससे पहले wheel बनाने के लिए उसे बिल्ड बैकएंड और सहायक पैकेज चाहिए हो सकते हैं।

इस क्रम में विफलता का पता लगाएँ: लक्ष्य आर्काइव प्राप्ति, बिल्ड आवश्यकताओं का इंस्टॉलेशन, बैकएंड निष्पादन, फिर परिणामी पैकेज का इंस्टॉलेशन। बैकएंड हुक अतिरिक्त बिल्ड आवश्यकताएँ माँग सकते हैं; वे पैकेज की रनटाइम निर्भरताओं से अलग हैं।

उस आर्टिफ़ैक्ट की पहचान करें जो pip को अभी भी चाहिए

“Installing build dependencies” पर विफल पैकेज और URL दर्ज करें। प्रभावी इंडेक्स, प्रॉक्सी मार्ग, खाता संदर्भ और उस अनुरोध के लिए भरोसा जाँचें, इंस्टॉल किए गए pip संस्करण की प्रलेखित सेटिंग्स का उपयोग करते हुए। पहले की सफल डाउनलोड हर होस्ट या हर सहायक के वातावरण तक पहुँच सिद्ध नहीं करती। सार्वजनिक बिल्ड आवश्यकताएँ HTTP प्रॉक्सी सूची से HTTP उम्मीदवार का उपयोग कर सकती हैं जब वह मार्ग अनुमत हो; आवश्यक इंडेक्स और भरोसा नीति बनाए रखें। ऐतिहासिक setup.py डाउनलोड रेसिपियाँ अलग उपप्रक्रियाओं का उपयोग कर सकती हैं।

यदि कोई दूसरी मशीन सफलतापूर्वक इंस्टॉल करती है, तो पहले चयनित आर्टिफ़ैक्ट की तुलना करें। उसके Python संस्करण या प्लेटफ़ॉर्म में संगत पूर्व-निर्मित wheel हो सकता है, जबकि इस मशीन ने सोर्स डिस्ट्रिब्यूशन चुना है और इसलिए उसे बिल्ड टूलींग चाहिए।

बिल्ड वातावरण जानबूझकर उपलब्ध कराएँ

--no-build-isolation आवश्यक बिल्ड निर्भरताओं की ज़िम्मेदारी आपको सौंपता है। यह प्रॉक्सी प्रमाणीकरण या प्रमाणपत्र भरोसे को ठीक नहीं करता। स्थानीय रूप से इंस्टॉल किया गया बैकएंड अनुपस्थित या असंगत आवश्यकता छिपा सकता है।

जानबूझकर ऑफ़लाइन बिल्ड के लिए, अनुमोदित प्रक्रिया से परियोजना और प्लेटफ़ॉर्म के लिए लक्ष्य आर्टिफ़ैक्ट, बिल्ड आवश्यकताएँ और आवश्यक टूलींग तैयार करें। केवल सोर्स आर्काइव वाली निर्देशिका अधूरी है। विफल आवश्यकता और चरण रिपोर्ट में रखें ताकि मार्ग या तैयार आर्टिफ़ैक्ट सेट सुधारा जा सके।

संबंधित लेख