Активація середовища 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 або в підтримуваних версіях і середовищах виконання Python вибирати системну довіру через truststore. Це не команда налаштування джерела довіри pip.

Якщо проксі виконує схвалену TLS-інспекцію, з’ясуйте, як кожен клієнт довіряє цьому центру сертифікації. Успішний запит Conda доводить, що його власні маршрут і довіра спрацювали для цього запиту; він не доводить, що pip отримав ті самі налаштування.

Порівняйте фактичні цілі

Клієнти можуть використовувати різні індекси пакунків і файлові хости. Посередник, який дозволяє один канал, може заборонити інший індекс або подальший URL архіву. Перевірте проблемне ім’я хоста й відповідь, перш ніж пояснювати різницю лише вибраним середовищем Python.

Корисний звіт указує інтерпретатор, джерело конфігурації кожного клієнта, запитаний хост і першу помилку з’єднання або сертифіката. «Conda працює» — початок порівняння, а не повна перевірка мережевого шляху pip.

Схожі статті