გადაეცით პროქსი pip პროცესს, რომელსაც იწყებთ
გამოიძახეთ pip განზრახული Python ინტერპრეტატორის მეშვეობით და მიაწოდეთ --proxy ცალკე subprocess არგუმენტად, pip-ის შიდა ნაწილების იმპორტის ნაცვლად.
როდესაც არსებულ provisioning სკრიპტს pip უნდა გაუშვას პროქსის მეშვეობით, გაუშვით pip subprocess-ად. pip-ის შიდა Python ფუნქციები არ არის მხარდაჭერილი აპლიკაციის 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 ინტერპრეტატორს, რითაც თავიდან იქნება აცილებული PATH-დან სხვა ინსტალაციის pip-ის შემთხვევითი გამოძახება.
თითოეული არგუმენტი იკავებს სიის ცალკე ელემენტს. Shell არ არის საჭირო და პროქსის URL-ს არ სჭირდება ჩაშენებული shell ბრჭყალების დამატებითი წყვილი. check=True აღძრავს CalledProcessError-ს, თუ ინსტალაცია ვერ მოხერხდა, რაც provisioning სამუშაო ნაკადს ამ შეცდომის დამუშავების საშუალებას აძლევს.
კონფიგურირეთ ჩამოტვირთვის მარშრუტი ამ pip გამოძახებაზე ან მის subprocess გარემოში. მშობელ პროგრამაში სხვაგან კონფიგურირებული Requests სესია არ აკონფიგურირებს pip-ის ცალკე პროცესს.
ინსტალაციის შემდეგ გააგრძელეთ აპლიკაციის გარემოს ჩვეულებრივი სასიცოცხლო ციკლი. უკვე მომუშავე ინტერპრეტატორში ინსტალაცია არ იძლევა გარანტიას, რომ მისი მიმდინარე იმპორტები, ქეშები ან ბილიკები დაუყოვნებლივ აისახება ახალ პაკეტს.