R-proxyindstillinger: pakkedownloads kontra API-forespørgsler

Hvis R kan installere en pakke, men pakken ikke kan nå sin API, skal du sammenligne de to anmodningsklienter. download.file(), RCurl og en pakkes eget HTTP-lag behøver ikke læse de samme indstillinger.

Kontroller den kørende sessions input

Et program startet fra en terminal arver terminalens miljø. En skrivebordsgenvej eller et IDE, der allerede kører, kan have andre værdier. Den relevante R-startmiljøfil kan indeholde:

http_proxy=http://proxy.example:8080
https_proxy=http://proxy.example:8080

Dette er miljøfilsposter med et eksempelslutpunkt. For offentlige pakke- eller API-anmodninger, der er tilladt gennem offentlige mellemled, tilbyder HTTP-proxylisten kandidater til disse værdier. R-udtryk som options(download.file.method = "libcurl") hører i R-kode, ikke i .Renviron. At placere den rigtigt udseende indstilling i det forkerte format efterlader den ubrugt.

Identificér den startfil, som R's regler for websted/bruger, miljø og arbejdsmappe vælger. En projektlokal fil kan forklare en forskel mellem to projekter i samme IDE. Ændr den tilsigtede fil, og genstart den relevante session; redigering opdaterer ikke den proces, der allerede kører.

Følg den fejlende pakkes anmodning

Identificér den faktiske downloadmetode eller HTTP-implementering. En ekstern curl-kørbar fil, R's libcurl-metode og RCurl er forskellige forbrugere med deres egne understøttede input. Sammenlign samme destination gennem den fejlende pakke med hemmeligheder fjernet.

Hold opskrifter tilpasset den pågældende implementering og R-udgivelse. Gammelt Windows---internet2-råd beskriver historisk adfærd. Bevar også den rigtige proxy-lytters transportskema: en HTTPS-destination kan stadig bruge et HTTP-proxy-slutpunkt. En vellykket installation gennem en anden downloader fastslår hverken denne klients konfiguration eller proxys tilgængelighed for denne anmodning.