Передайте проксі процесу pip, який ви запускаєте

Викликайте pip через потрібний інтерпретатор Python і передавайте --proxy окремим аргументом subprocess замість імпорту внутрішніх частин pip.

Коли наявний скрипт підготовки має запустити pip через проксі, запускайте pip як subprocess. Внутрішні функції Python у pip не є підтримуваним API застосунку.

import subprocess
import sys

subprocess.run([
    sys.executable,
    '-m', 'pip', 'install',
    '--proxy', 'http://proxy.example:8080',
    'example-package',
], check=True)

Використовуйте потрібний пакет і кінцеву точку проксі. Для завантажень публічних пакетів, дозволених через публічного посередника, список HTTP-проксі пропонує кандидатів для аргументу HTTP-проксі. sys.executable вибирає інтерпретатор Python, який виконує скрипт, тому випадковий виклик pip іншого встановлення з PATH унеможливлюється.

Кожен аргумент займає окремий елемент списку. Оболонка не потрібна, і URL проксі не потребує додаткової пари вбудованих лапок оболонки. check=True викликає CalledProcessError, якщо встановлення не вдалося, що дозволяє робочому процесу підготовки обробити цю помилку.

Налаштуйте маршрут завантаження в цьому виклику pip або в середовищі його subprocess. Сеанс Requests, налаштований в іншому місці батьківської програми, не налаштовує окремий процес pip.

Після встановлення продовжуйте звичайний життєвий цикл середовища застосунку. Встановлення в інтерпретатор, який уже працює, не гарантує, що його поточні імпорти, кеші чи шляхи одразу відображають новий пакет.

Схожі статті