Gitt de Proxy un de pip-Prozess, deen Dir start

Rufft pip iwwer den agesaten Python-Interpreter un a gitt --proxy als separate Subprocess-Argument, amplaz d'Interna vum pip ze importéieren.

Wann en existente Provisioning-Skript de pip iwwer e Proxy muss lafe loossen, start de pip als Subprocess. D'intern Python-Funktioune vu pip sinn keng ënnerstëtzt Applikatiouns-API.

import subprocess
import sys

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

Benotzt de virgesiichte Package an den Endpunkt vum Proxy. Fir ëffentlech Package-Downloads, déi iwwer en ëffentlechen Intermédiaire erlaabt sinn, bitt d'HTTP-Proxy-Lëscht Kandidaten fir d'HTTP-Proxy-Argument. sys.executable wielt den Python-Interpreter, deen de Skript ausféiert, sou datt vermeit gëtt, versehentlech de pip vun enger anerer Installatioun aus dem PATH opzeruffen.

All Argument hëlt e separat Lëschtelement an. Et ass keng Shell noutwenneg, an d'Proxy-URL brauch kee zousätzlecht Pair agebaut Shell-Anféierungszeechen. check=True léisst CalledProcessError aus, wann d'Installatioun feelt, sou datt den Provisioning-Workflow dëse Feeler ka behandelen.

Konfiguréiert de Downloadwee bei dësem pip-Opruff oder an der Subprocess-Ëmgebung dovun. Eng Requests-Sessioun, déi soss anzwousch am Eltereprogramm konfiguréiert ass, konfiguréiert den separate pip-Prozess net.

No der Installatioun fuert de normale Liewenszyklus vun der Ëmgebung vun der Applikatioun weider. An en Interpreter ze installéieren, deen schonn leeft, garantéiert net, datt seng aktuell Importen, Caches oder Weeër dee neie Package direkt reflektéieren.

Ähnlech Artikelen