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 ومن pip المرتبط بنسخة Python النشطة:

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

قد تكشف المخرجات مواقع إعدادات مختلفة، أو مفسرًا غير متوقع، أو متغير بيئة لم يستخدمه أحد الاختبارات. راجع عناوين URL الخاصة وبيانات الاعتماد قبل مشاركتها.

بالنسبة إلى pip، استخدم خيار الوكيل الموثق له أو إعدادات pip الخاصة أو بيئة الشبكة المناسبة. لا تنسخ قسم YAML من .condarc مباشرة إلى ملف INI الخاص بـpip.

إعدادات الثقة منفصلة أيضًا

يمكن لإعداد ssl_verify في Conda تحديد حزمة CA أو اختيار ثقة النظام باستخدام truststore في الإصدارات وبيئات تشغيل Python المدعومة. وليس ذلك أمرًا لضبط مصدر الثقة لدى pip.

إذا كان الوكيل يجري فحص TLS معتمدًا، فحدد كيف يثق كل عميل بتلك الجهة. نجاح طلب Conda يثبت أن مساره وثقته عملا لذلك الطلب؛ ولا يثبت أن pip تلقى الإعداد نفسه.

قارن الوجهات الفعلية

قد يستخدم العميلان فهارس حزم ومضيفي ملفات مختلفين. قد يسمح وسيط بقناة ويرفض فهرسًا آخر أو عنوان URL لاحقًا لأرشيف. افحص اسم المضيف الذي يفشل والاستجابة قبل عزو الفرق إلى بيئة Python المختارة وحدها.

يحدد التقرير المفيد المفسر ومصدر إعدادات كل عميل والمضيف المطلوب وأول خطأ اتصال أو شهادة. عبارة «Conda يعمل» بداية مقارنة، وليست اختبارًا كاملًا لمسار شبكة pip.