Conda fungerar genom proxyn, men pip gör det inte

Att aktivera en Conda-miljö väljer en miljö; det får inte alla program i den att använda Condas konfiguration. Conda och pip är separata nedladdningsklienter.

Conda kan ha proxyrutter i .condarc:

proxy_servers:
  http: http://203.0.113.10:8080
  https: http://203.0.113.10:8080

Dessa exempelvärden talar om för Conda hur mål för varje schema nås. pip tar inte automatiskt över mappningen proxy_servers bara för att det är installerat i den miljön.

Granska båda konfigurationerna

Kontrollera Condas konfigurationskällor och pip som hör till den aktiva Python:

conda config --show-sources
python -m pip --version
python -m pip config debug

Utdata kan visa olika konfigurationsplatser, en oväntad tolk eller en miljövariabel som ett test inte använde. Granska privata URL:er och inloggningsuppgifter före delning.

För pip, använd det dokumenterade proxyalternativet, pip-specifik konfiguration eller lämplig nätverksmiljö. Kopiera inte en YAML-sektion från .condarc direkt till en INI-fil för pip.

Tillitsinställningarna är också separata

Condas ssl_verify kan ange en CA-samling eller i stödda versioner och Python-körmiljöer välja systemtillit med truststore. Det är inget kommando för att konfigurera pips tillitskälla.

Om proxyn utför godkänd TLS-inspektion, ta reda på hur varje klient litar på den utfärdaren. En lyckad Conda-begäran bevisar att dess egen rutt och tillit fungerade för just den begäran; inte att pip fick samma inställningar.

Jämför de faktiska målen

Klienterna kan använda olika paketindex och filvärdar. En mellanhand som tillåter en kanal kan neka ett annat index eller en senare arkiv-URL. Kontrollera värdnamnet som misslyckas och svaret innan du tillskriver skillnaden enbart den valda Python-miljön.

En användbar rapport anger tolken, varje klients konfigurationskälla, den begärda värden och det första anslutnings- eller certifikatfelet. ”Conda fungerar” är början på en jämförelse, inte ett fullständigt test av pips nätverksväg.