I download dal registry di Cargo funzionano, ma le dipendenze Git falliscono

Leggi l’URL della sorgente che ha fallito prima di modificare il proxy di Cargo. Metadati del registry, un archivio crate e una dipendenza Git possono usare percorsi diversi per recupero e autenticazione. Un URL Git SSH richiede anche un assetto di trasporto diverso da HTTPS.

Per le richieste HTTP pertinenti di Cargo, il percorso può essere impostato così:

[http]
proxy = "http://203.0.113.10:8080"

Sostituisci l’endpoint della documentazione con il tuo proxy HTTP. Per un percorso di registry pubblico autorizzato a usare proxy pubblici, i candidati sono nella lista dei proxy HTTP. Questo non dimostra che un eseguibile Git esterno abbia ricevuto la stessa configurazione.

Se la sorgente che fallisce è Git, Cargo può selezionare il Git CLI invece dell’implementazione integrata:

[net]
git-fetch-with-cli = true

CARGO_NET_GIT_FETCH_WITH_CLI=true lo seleziona per un comando. Ora Git esterno richiede la propria configurazione proxy e le credenziali. Confronta lo stesso URL Git nello stesso ambiente di avvio; un repository non correlato che funziona in un altro terminale non è il test.

Una revisione mancante, il permesso del repository negato o un errore della host key SSH restano lo stesso problema dopo il cambio di implementazione. L’opzione consente di scegliere un client supportato, non ripara le dipendenze in generale.

Mantieni la diagnosi nell’ambito del progetto o del comando: le impostazioni Git globali e quelle Cargo dell’utente possono influire su altri workspace. Un URL di registry seleziona dati del pacchetto, non un intermediario. Quando il percorso Git funziona, riesegui l’intera operazione Cargo prevista perché archivi, reindirizzamenti e download durante la build possono introdurre altri percorsi.