R-Proxy-Einstellungen: Paketdownloads versus API-Anfragen
Verfolgen Sie die Umgebung der R-Sitzung und den HTTP-Client, den ein Paket tatsächlich verwendet, statt inkompatible Proxy-Rezepte aus alten R-Versionen zu kombinieren.
Wenn R ein Paket installieren kann, das Paket aber seine API nicht erreicht, vergleichen Sie die beiden anfragenden Clients. download.file(), RCurl und die eigene HTTP-Schicht eines Pakets müssen nicht dieselben Optionen lesen.
Eingaben der laufenden Sitzung prüfen
Ein aus einem Terminal gestartetes Programm erbt die Umgebung dieses Terminals. Eine Desktop-Verknüpfung oder eine bereits laufende IDE kann andere Werte haben. Die passende R-Startumgebungsdatei kann enthalten:
http_proxy=http://proxy.example:8080
https_proxy=http://proxy.example:8080Dies sind Einträge in einer Umgebungsdatei mit einem Beispiel-Endpunkt. Für öffentliche Paket- oder API-Anfragen, die über öffentliche Vermittler erlaubt sind, bietet die HTTP-Proxy-Liste Kandidaten für diese Werte. R-Ausdrücke wie options(download.file.method = "libcurl") gehören in R-Code, nicht in .Renviron. Eine richtig aussehende Einstellung im falschen Format bleibt ungenutzt.
Ermitteln Sie die Startdatei, die R durch seine Regeln für Site/Benutzer, Umgebung und Arbeitsverzeichnis auswählt. Eine projektlokale Datei kann einen Unterschied zwischen zwei Projekten in derselben IDE erklären. Ändern Sie die vorgesehene Datei und starten Sie die betreffende Sitzung neu; das Bearbeiten aktualisiert einen bereits laufenden Prozess nicht.
Der Anfrage des fehlschlagenden Pakets folgen
Ermitteln Sie die tatsächliche Downloadmethode oder HTTP-Implementierung. Eine externe curl-Binärdatei, Rs libcurl-Methode und RCurl sind unterschiedliche Verbraucher mit eigenen unterstützten Eingaben. Vergleichen Sie dasselbe Ziel über das fehlschlagende Paket, wobei Geheimnisse entfernt sind.
Halten Sie Rezepte mit dieser Implementierung und R-Version abgestimmt. Alter Windows---internet2-Rat beschreibt historisches Verhalten. Behalten Sie auch das Transportschema des tatsächlichen Proxy-Listeners bei: Ein HTTPS-Ziel kann weiterhin einen HTTP-Proxy-Endpunkt verwenden. Eine erfolgreiche Installation über einen anderen Downloader belegt weder die Konfiguration dieses Clients noch die Verfügbarkeit des Proxys für diese Anfrage.