Hvorfor pip henter build-afhængigheder, før din pakke installeres

Et lokalt kildearkiv kan stadig kræve netværksadgang. Før pip kan installere det, kan pip have brug for en build-backend og understøttende pakker for at bygge en wheel.

Find fejlen i denne rækkefølge: hentning af målarkivet, installation af build-krav, kørsel af backenden og derefter installation af den resulterende pakke. Backend-hooks kan anmode om yderligere build-krav; de er adskilt fra pakkens runtime-afhængigheder.

Identificér det artefakt, pip stadig mangler

Ved “Installing build dependencies” skal du notere den fejlede pakke og URL. Undersøg det effektive indeks, proxy-ruten, kontokonteksten og tilliden for den anmodning, med den installerede pip-versions dokumenterede indstillinger. En tidligere vellykket download beviser ikke adgang til hver vært eller hver hjælpeproces' miljø. Offentlige build-krav kan bruge en HTTP-kandidat fra HTTP-proxylisten, når den rute er tilladt; bevar det krævede indeks og tillidspolitikken. Historiske setup.py download-opskrifter kan bruge andre underprocesser.

Hvis en anden maskine installerer med succes, skal du først sammenligne de valgte artefakter. Dens Python-version eller platform har måske en kompatibel forudbygget wheel, mens denne maskine valgte en kildedistribution og derfor har brug for build-værktøjer.

Lever build-miljøet bevidst

--no-build-isolation overfører ansvaret for de nødvendige build-afhængigheder til dig. Det reparerer ikke proxy-godkendelse eller certifikattillid. En lokalt installeret backend kan skjule et manglende eller inkompatibelt krav.

Til et bevidst offline build skal du forberede målartefaktet, build-kravene og det nødvendige værktøj til projektet og platformen via den godkendte proces. En mappe, der kun indeholder kildearkivet, er ufuldstændig. Bevar det fejlede krav og trin i rapporten, så enten ruten eller det forberedte artefaktsæt kan rettes.