Conda प्रॉक्सी के ज़रिए काम करता है, लेकिन pip नहीं

Conda वातावरण सक्रिय करना एक वातावरण चुनता है; उसके भीतर के हर प्रोग्राम को Conda की कॉन्फ़िगरेशन इस्तेमाल करने पर मजबूर नहीं करता। Conda और pip अलग डाउनलोड क्लाइंट हैं।

Conda में .condarc के अंदर प्रॉक्सी रूट हो सकते हैं:

proxy_servers:
  http: http://203.0.113.10:8080
  https: http://203.0.113.10:8080

ये उदाहरण मान Conda को बताते हैं कि हर स्कीम के गंतव्य तक कैसे पहुँचना है। pip केवल उस वातावरण में इंस्टॉल होने के कारण proxy_servers मैपिंग अपने-आप नहीं अपनाता।

दोनों कॉन्फ़िगरेशन जाँचें

Conda के कॉन्फ़िगरेशन स्रोत और सक्रिय Python से जुड़े pip को जाँचें:

conda config --show-sources
python -m pip --version
python -m pip config debug

आउटपुट अलग कॉन्फ़िगरेशन स्थान, अनपेक्षित इंटरप्रेटर या ऐसा पर्यावरण चर दिखा सकता है जिसे किसी टेस्ट ने इस्तेमाल नहीं किया। साझा करने से पहले निजी URL और क्रेडेंशियल देखें।

pip के लिए उसका दस्तावेज़ित प्रॉक्सी विकल्प, pip-विशिष्ट कॉन्फ़िगरेशन या उपयुक्त नेटवर्क वातावरण इस्तेमाल करें। .condarc का YAML भाग सीधे pip की INI फ़ाइल में कॉपी न करें।

विश्वास सेटिंग भी अलग हैं

Conda का ssl_verify CA बंडल बता सकता है या समर्थित संस्करण और Python रनटाइम में truststore से सिस्टम ट्रस्ट चुन सकता है। यह pip के ट्रस्ट स्रोत को कॉन्फ़िगर करने का आदेश नहीं है।

अगर प्रॉक्सी स्वीकृत TLS निरीक्षण करता है, तो तय करें कि हर क्लाइंट उस प्राधिकरण पर कैसे भरोसा करता है। सफल Conda अनुरोध यह साबित करता है कि उस अनुरोध के लिए उसकी अपनी रूट और ट्रस्ट काम कर रहे थे; यह नहीं कि pip को वही सेटिंग मिली।

वास्तविक गंतव्यों की तुलना करें

क्लाइंट अलग पैकेज इंडेक्स और फ़ाइल होस्ट इस्तेमाल कर सकते हैं। एक चैनल को अनुमति देने वाला मध्यस्थ दूसरे इंडेक्स या बाद के आर्काइव URL को अस्वीकार कर सकता है। अंतर को केवल चुने गए Python वातावरण पर डालने से पहले विफल हो रहे होस्टनाम और उत्तर जाँचें।

उपयोगी रिपोर्ट में इंटरप्रेटर, प्रत्येक क्लाइंट का कॉन्फ़िगरेशन स्रोत, अनुरोधित होस्ट और पहली कनेक्शन या प्रमाणपत्र त्रुटि बताई जाती है। “Conda काम करता है” तुलना की शुरुआत है, pip के नेटवर्क पथ का पूरा परीक्षण नहीं।