Cargo registry ഡൗൺലോഡുകൾ പ്രവർത്തിക്കുന്നു, പക്ഷേ Git dependencies പരാജയപ്പെടുന്നു
Cargo registry-യുടെ HTTP പാത Git ഉറവിടങ്ങൾ നേടുന്നതിൽ നിന്ന് വേർതിരിച്ച് proxy പെരുമാറ്റം വ്യത്യസ്തമായപ്പോൾ Git implementation മനപ്പൂർവ്വം തിരഞ്ഞെടുക്കുക.
Cargo-യുടെ proxy മാറ്റുന്നതിന് മുമ്പ് പരാജയപ്പെട്ട source URL വായിക്കുക. Registry metadata, crate archive, Git dependency എന്നിവ fetching-നും authentication-നും വ്യത്യസ്ത പാതകൾ ഉപയോഗിച്ചേക്കാം. SSH Git URL-ന് HTTPS-ൽ നിന്ന് വ്യത്യസ്തമായ transport arrangement ആവശ്യമാണ്.
Cargo-യുടെ പ്രസക്തമായ HTTP requests-ക്ക് route ഇങ്ങനെ ക്രമീകരിക്കാം:
[http]
proxy = "http://203.0.113.10:8080"Documentation endpoint-ന് പകരം നിങ്ങളുടെ HTTP proxy നൽകുക. Public proxies ഉപയോഗിക്കാൻ അനുവദിച്ച public registry path-നുള്ള candidates HTTP proxy list-ൽ ഉണ്ട്. External Git executable-ന് അതേ configuration ലഭിച്ചു എന്ന് ഇത് തെളിയിക്കുന്നില്ല.
പരാജയപ്പെട്ട source Git ആണെങ്കിൽ, Cargo built-in implementation-ന് പകരം Git CLI തിരഞ്ഞെടുക്കാം:
[net]
git-fetch-with-cli = trueCARGO_NET_GIT_FETCH_WITH_CLI=true ഒറ്റ command-ിനായി അത് തിരഞ്ഞെടുക്കുന്നു. External Git-ന് ഇപ്പോൾ സ്വന്തം proxy configurationയും credentials-ഉം വേണം. അതേ launch environment-ൽ അതേ Git URL താരതമ്യം ചെയ്യുക; മറ്റൊരു terminal-ൽ പ്രവർത്തിക്കുന്ന unrelated repository പരീക്ഷണമല്ല.
Missing revision, repository permission denial, SSH host-key error എന്നിവ implementation മാറ്റിയ ശേഷവും അതേ പ്രശ്നങ്ങളാണ്. ഈ option supported client തിരഞ്ഞെടുക്കാനുള്ള വഴിയാണ്, പൊതുവായ dependency repair അല്ല.
Diagnosis project അല്ലെങ്കിൽ command scope-ൽ നിർത്തുക: global Git, user Cargo settings എന്നിവ മറ്റ് workspaces-നെ ബാധിക്കാം. Registry URL package data തിരഞ്ഞെടുക്കുന്നു, intermediary അല്ല. Git path പ്രവർത്തിച്ച ശേഷം പൂർണ്ണ intended Cargo operation വീണ്ടും നടത്തുക; archives, redirects, build-time downloads എന്നിവ മറ്റ് routes ചേർത്തേക്കാം.