Hvorfor pip laster ned byggeavhengigheter før pakken din installeres

Et lokalt kildearkiv kan fortsatt kreve nettverkstilgang. Før pip kan installere det, kan pip trenge en byggebackend og støttepakker for å lage en wheel.

Finn feilen i denne rekkefølgen: henting av målarkivet, installasjon av byggekrav, kjøring av backenden og deretter installasjon av den resulterende pakken. Backend-kroker kan be om flere byggekrav; disse er atskilt fra pakkens kjøretidsavhengigheter.

Identifiser artefakten pip fortsatt trenger

Ved «Installing build dependencies» noterer du den feilede pakken og URL-en. Undersøk den effektive indeksen, proxy-ruten, kontokonteksten og tilliten for den forespørselen, med de dokumenterte innstillingene til den installerte pip-versjonen. En tidligere vellykket nedlasting beviser ikke tilgang til hver vert eller miljøet til hver hjelper. Offentlige byggekrav kan bruke en HTTP-kandidat fra HTTP-proxylisten når den ruten er tillatt; behold den påkrevde indeksen og tillitspolicyen. Historiske setup.py nedlastingsoppskrifter kan bruke andre underprosesser.

Hvis en annen maskin installerer med hell, sammenlign de valgte artefaktene først. Dens Python-versjon eller plattform kan ha en kompatibel forhåndsbygd wheel, mens denne maskinen valgte en kildedistribusjon og derfor trenger byggeverktøy.

Skaff byggemiljøet med vilje

--no-build-isolation overfører ansvaret for de nødvendige byggeavhengighetene til deg. Det reparerer ikke proxy-autentisering eller sertifikattillit. En lokalt installert backend kan skjule et manglende eller inkompatibelt krav.

For et bevisst offline bygg, klargjør målartefakten, byggekravene og verktøyene som trengs for prosjektet og plattformen gjennom den godkjente prosessen. En mappe som bare inneholder kildearkivet, er ufullstendig. Behold det feilede kravet og trinnet i rapporten slik at enten ruten eller det klargjorte artefaktsettet kan rettes.