Pobieranie z rejestru Cargo działa, ale zależności Git zawodzą

Oddziel ścieżkę HTTP rejestru Cargo od pobierania źródeł Git i świadomie wybierz implementację Git, gdy zachowanie proxy jest inne.

Przeczytaj URL nieudanego źródła przed zmianą proxy Cargo. Metadane rejestru, archiwum crate i zależność Git mogą używać różnych ścieżek pobierania i uwierzytelniania. URL Git przez SSH wymaga też innego układu transportu niż HTTPS.

Dla odpowiednich żądań HTTP Cargo trasę można ustawić tak:

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

Zastąp endpoint dokumentacji własnym proxy HTTP. Dla publicznej ścieżki rejestru, która może używać publicznych proxy, kandydaci są w liście proxy HTTP. Nie dowodzi to, że zewnętrzny plik wykonywalny Git otrzymał tę samą konfigurację.

Jeśli nieudane źródło to Git, Cargo może wybrać Git CLI zamiast wbudowanej implementacji:

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

CARGO_NET_GIT_FETCH_WITH_CLI=true wybiera go dla jednego polecenia. Zewnętrzny Git potrzebuje teraz własnej konfiguracji proxy i danych uwierzytelniających. Porównaj ten sam URL Git w tym samym środowisku uruchomieniowym; niezwiązane repozytorium działające w innym terminalu nie jest testem.

Brak rewizji, odmowa uprawnień do repozytorium lub błąd klucza hosta SSH pozostają tym samym problemem po zmianie implementacji. Opcja wybiera obsługiwanego klienta, ale nie naprawia ogólnie zależności.

Trzymaj diagnozę w zakresie projektu lub polecenia: globalne ustawienia Git i ustawienia Cargo użytkownika mogą wpływać na inne obszary robocze. URL rejestru wybiera dane pakietu, a nie pośrednika. Gdy ścieżka Git działa, ponownie uruchom całą zamierzoną operację Cargo, ponieważ archiwa, przekierowania i pobieranie podczas budowania mogą dodać inne trasy.

Powiązane artykuły