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

خروجی‌ها می‌توانند مکان‌های متفاوت پیکربندی، مفسر غیرمنتظره یا متغیر محیطی استفاده‌نشده در یکی از آزمون‌ها را آشکار کنند. نشانی‌های خصوصی و اطلاعات ورود را پیش از اشتراک‌گذاری مرور کنید.

برای pip، از گزینهٔ پراکسی مستندشدهٔ آن، پیکربندی ویژهٔ pip یا محیط شبکهٔ مناسب استفاده کنید. بخش YAML فایل .condarc را مستقیم در فایل INI مربوط به pip کپی نکنید.

تنظیمات اعتماد هم جدا هستند

ssl_verify در Conda می‌تواند بستهٔ CA را مشخص کند یا در نسخه‌ها و محیط‌های اجرای Python پشتیبانی‌شده، با truststore اعتماد سیستم را انتخاب کند. این فرمان تنظیم منبع اعتماد pip نیست.

اگر پراکسی بازرسی TLS تأییدشده انجام می‌دهد، مشخص کنید هر کلاینت چگونه به آن مرجع اعتماد می‌کند. درخواست موفق Conda ثابت می‌کند مسیر و اعتماد خودش برای همان درخواست کار کرده‌اند؛ ثابت نمی‌کند pip همان تنظیمات را گرفته است.

مقصدهای واقعی را مقایسه کنید

کلاینت‌ها ممکن است از نمایه‌های بسته و میزبان‌های فایل متفاوت استفاده کنند. واسطی که یک کانال را مجاز می‌داند ممکن است نمایه‌ای دیگر یا نشانی آرشیو بعدی را رد کند. پیش از نسبت دادن تفاوت فقط به محیط Python انتخاب‌شده، نام میزبان ناموفق و پاسخ را بررسی کنید.

گزارش مفید مفسر، منبع پیکربندی هر کلاینت، میزبان درخواستی و نخستین خطای اتصال یا گواهی را مشخص می‌کند. «Conda کار می‌کند» آغاز مقایسه است، نه آزمون کامل مسیر شبکهٔ pip.