Kvifor pip lastar ned byggjeavhengnader før pakken din vert installert

Eit lokalt kjeldarkiv kan framleis krevje nettilgang. Før pip kan installere det, kan pip trenge ein byggjebackend og støttepakkar for å lage ein wheel.

Finn feilen i denne rekkjefølgja: henting av målarkivet, installasjon av byggjekrava, køyring av backend, og deretter installasjon av den resulterande pakken. Backend-krokar kan be om fleire byggjekrav; desse er skilde frå køyretidsavhengnadene til pakken.

Identifiser artefakten pip framleis treng

Ved «Installing build dependencies» noterer du den feila pakken og URL-en. Gransk den effektive indeksen, proxy-ruta, kontokonteksten og tilliten for den førespurnaden, med dei dokumenterte innstillingane til den installerte pip-versjonen. Ei tidlegare vellukka nedlasting provar ikkje tilgang til kvar vert eller miljøet til kvar hjelpar. Offentlege byggjekrav kan bruke ein HTTP-kandidat frå HTTP-proxylista når den ruta er tillaten; hald på den påkravde indeksen og tillitspolitikken. Historiske setup.py nedlastingsoppskrifter kan bruke andre underprosessar.

Viss ein annan maskin installer med hell, samanlikn dei valde artefaktane først. Dens Python-versjon eller plattform kan ha ein kompatibel førehandsbygd wheel, medan denne maskinen valde ein kjeldedistribusjon og difor treng byggjeverktøy.

Skaff byggjemiljøet med vilje

--no-build-isolation flyttar ansvaret for dei naudsynte byggjeavhengnadene til deg. Det reparerer ikkje proxy-autentisering eller sertifikattillit. Ein lokalt installert backend kan skjule eit manglande eller inkompatibelt krav.

For eit medvite offline bygg, klargjer målartefakten, byggjekrava og verktøya som trengst for prosjektet og plattforma gjennom den godkjende prosessen. Ei mappe som berre inneheld kjeldarkivet, er ufullstendig. Hald på det feila kravet og trinnet i rapporten slik at anten ruta eller det klargjorde artefaktsettet kan rettast.