Ustawienia proxy w R: pobieranie pakietów a żądania API

Jeśli R potrafi zainstalować pakiet, ale ten pakiet nie dociera do swojego API, porównaj dwóch klientów wysyłających żądania. download.file(), RCurl i własna warstwa HTTP pakietu nie muszą czytać tych samych opcji.

Sprawdź dane wejściowe działającej sesji

Program uruchomiony z terminala dziedziczy środowisko tego terminala. Skrót na pulpicie lub już działające IDE mogą mieć inne wartości. Odpowiedni plik środowiska startowego R może zawierać:

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

To wpisy pliku środowiska z przykładowym punktem końcowym. Dla publicznych żądań do pakietów lub API dozwolonych przez publicznych pośredników lista proxy HTTP oferuje kandydatów na te wartości. Wyrażenia R takie jak options(download.file.method = "libcurl") należą do kodu R, a nie do .Renviron. Umieszczenie poprawnie wyglądającego ustawienia w złym formacie pozostawia je nieużyte.

Zidentyfikuj plik startowy wybierany przez reguły R dotyczące witryny/użytkownika, środowiska i katalogu roboczego. Plik w projekcie może wyjaśnić różnicę między dwoma projektami w tym samym IDE. Zmień zamierzony plik i uruchom ponownie odpowiednią sesję; edycja nie aktualizuje już działającego procesu.

Śledź żądanie zawodzącego pakietu

Zidentyfikuj rzeczywistą metodę pobierania lub implementację HTTP. Zewnętrzny plik wykonywalny curl, metoda libcurl w R i RCurl to odrębni konsumenci z własnymi obsługiwanymi danymi wejściowymi. Porównaj ten sam cel przez zawodzący pakiet, z ukrytymi sekretami.

Utrzymuj przepisy zgodne z tą implementacją i wydaniem R. Stara porada dotycząca Windows --internet2 opisuje historyczne zachowanie. Zachowaj też schemat transportu rzeczywistego nasłuchującego proxy: cel HTTPS nadal może używać punktu końcowego proxy HTTP. Udana instalacja przez inny downloader nie potwierdza ani konfiguracji tego klienta, ani dostępności proxy dla tego żądania.