R-proxyinnstillinger: pakkenedlastinger kontra API-forespørsler

Hvis R kan installere en pakke, men pakken ikke når API-et sitt, sammenlign de to forespørselsklientene. download.file(), RCurl og en pakkes eget HTTP-lag trenger ikke lese de samme innstillingene.

Kontroller inndataene til den kjørende økten

Et program startet fra en terminal arver terminalens miljø. En skrivebordsnøkkel eller et IDE som allerede kjører kan ha andre verdier. Den riktige R-oppstartsmiljøfilen kan inneholde:

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

Dette er miljøfiloppføringer med et eksempelendepunkt. For offentlige pakke- eller API-forespørsler som tillates gjennom offentlige mellomledd, tilbyr HTTP-proxylisten kandidater for disse verdiene. R-uttrykk som options(download.file.method = "libcurl") hører i R-kode, ikke i .Renviron. Å plassere den riktig utseende innstillingen i feil format lar den stå ubrukt.

Identifiser oppstartsfilen som velges av Rs regler for nettsted/bruker, miljø og arbeidskatalog. En prosjektlokal fil kan forklare en forskjell mellom to prosjekter i samme IDE. Endre den tiltenkte filen og start den relevante økten på nytt; redigering oppdaterer ikke prosessen som allerede kjører.

Følg forespørselen til pakken som feiler

Identifiser den faktiske nedlastingsmetoden eller HTTP-implementasjonen. En ekstern curl-kjørbar fil, Rs libcurl-metode og RCurl er ulike forbrukere med egne støttede inndata. Sammenlign samme destinasjon gjennom pakken som feiler, med hemmeligheter skjult.

Hold oppskrifter tilpasset den implementasjonen og R-utgivelsen. Gammelt Windows---internet2-råd beskriver historisk atferd. Behold også den ekte proxy-lytterens transportskjema: en HTTPS-destinasjon kan fortsatt bruke et HTTP-proxyendepunkt. En vellykket installasjon gjennom en annen nedlaster fastslår verken denne klientens konfigurasjon eller proxys tilgjengelighet for denne forespørselen.