Setări de proxy în R: descărcări de pachete versus cereri API

Dacă R poate instala un pachet, dar acel pachet nu își poate atinge API-ul, comparați cei doi clienți care trimit cereri. download.file(), RCurl și stratul HTTP propriu al unui pachet nu trebuie să citească aceleași opțiuni.

Verificați intrările sesiunii în execuție

Un program lansat dintr-un terminal moștenește mediul acelui terminal. O comandă rapidă de pe desktop sau un IDE deja pornit poate avea alte valori. Fișierul de mediu de pornire R potrivit poate conține:

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

Sunt intrări de fișier de mediu cu un endpoint exemplu. Pentru cereri publice către pachete sau API permise prin intermediari publici, lista de proxy HTTP oferă candidați pentru acele valori. Expresiile R precum options(download.file.method = "libcurl") aparțin codului R, nu fișierului .Renviron. Plasarea setării care pare corectă în formatul greșit o lasă nefolosită.

Identificați fișierul de pornire ales de regulile R privind site-ul/utilizatorul, mediul și directorul de lucru. Un fișier din interiorul proiectului poate explica o diferență între două proiecte din același IDE. Schimbați fișierul dorit și reporniți sesiunea relevantă; editarea lui nu actualizează procesul deja în execuție.

Urmăriți cererea pachetului care eșuează

Identificați metoda reală de descărcare sau implementarea HTTP. Un executabil curl extern, metoda libcurl a R și RCurl sunt consumatori distincți cu propriile intrări acceptate. Comparați aceeași destinație prin pachetul care eșuează, cu secretele ascunse.

Mențineți rețetele aliniate la implementarea și versiunea R respective. Sfatul vechi pentru Windows --internet2 descrie un comportament istoric. Păstrați și schema de transport a adevăratului listener de proxy: o destinație HTTPS poate folosi în continuare un endpoint de proxy HTTP. O instalare reușită prin alt descărcător nu stabilește nici configurația acestui client, nici disponibilitatea proxy-ului pentru această cerere.