Varför pip hämtar byggberoenden innan paketet installeras

Ett lokalt källarkiv kan fortfarande kräva nätverksåtkomst. Innan pip kan installera det kan pip behöva en byggbackend och stödpaket för att skapa en wheel.

Hitta felet i denna ordning: hämtning av målarkivet, installation av byggkraven, körning av backenden och sedan installation av det resulterande paketet. Backend-krokar kan begära ytterligare byggkrav; dessa är åtskilda från paketets körtidsberoenden.

Identifiera den artefakt som pip fortfarande behöver

Vid ”Installing build dependencies” noterar du det misslyckade paketet och URL:en. Granska det effektiva indexet, proxyvägen, kontokontexten och förtroendet för den begäran, med den installerade pip-versionens dokumenterade inställningar. En tidigare lyckad nedladdning bevisar inte åtkomst till varje värd eller varje hjälpares miljö. Offentliga byggkrav kan använda en HTTP-kandidat från HTTP-proxylistan när den vägen är tillåten; behåll det obligatoriska indexet och förtroendepolicyn. Historiska setup.py nedladdningsrecept kan använda andra underprocesser.

Om en annan maskin installerar framgångsrikt, jämför först de valda artefakterna. Dess Python-version eller plattform kan ha en kompatibel förbyggd wheel, medan den här maskinen valde en källdistribution och därför behöver byggverktyg.

Tillhandahåll byggmiljön medvetet

--no-build-isolation överför ansvaret för de nödvändiga byggberoendena till dig. Det reparerar inte proxyautentisering eller certifikatförtroende. En lokalt installerad backend kan dölja ett saknat eller inkompatibelt krav.

För ett medvetet offlinebygge förbereder du målartefakten, byggkraven och verktygen som behövs för projektet och plattformen via den godkända processen. En katalog som bara innehåller källarkivet är ofullständig. Behåll det misslyckade kravet och steget i rapporten så att antingen vägen eller den förberedda artefaktuppsättningen kan rättas.