Налаштування проксі в R: завантаження пакетів проти запитів до API

Якщо R може встановити пакет, але цей пакет не може досягти свого API, порівняйте двох клієнтів запитів. download.file(), RCurl і власний HTTP-шар пакета не зобов'язані читати ті самі параметри.

Перевірте вхідні дані поточного сеансу

Програма, запущена з термінала, успадковує середовище цього термінала. Ярлик на робочому столі або вже запущена IDE можуть мати інші значення. Відповідний файл середовища запуску R може містити:

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

Це записи файлу середовища з прикладом кінцевої точки. Для публічних запитів до пакетів або API, дозволених через публічних посередників, список HTTP-проксі пропонує кандидатів для цих значень. Вирази R, такі як options(download.file.method = "libcurl"), належать до коду R, а не до .Renviron. Розміщення правильно виглядаючого налаштування в неправильному форматі залишає його невикористаним.

Визначте файл запуску, який обирають правила R щодо сайту/користувача, середовища та робочого каталогу. Файл у межах проєкту може пояснити різницю між двома проєктами в одній IDE. Змініть потрібний файл і перезапустіть відповідний сеанс; редагування не оновлює вже запущений процес.

Прослідкуйте запит пакета, що не працює

Визначте фактичний метод завантаження або реалізацію HTTP. Зовнішній виконуваний файл curl, метод libcurl у R і RCurl — це окремі споживачі з власними підтримуваними входами. Порівняйте ту саму мету через пакет, що не працює, приховавши секрети.

Тримайте рецепти узгодженими з цією реалізацією та випуском R. Стара порада для Windows --internet2 описує історичну поведінку. Зберігайте також схему транспорту справжнього слухача проксі: призначення HTTPS усе ще може використовувати кінцеву точку проксі HTTP. Успішне встановлення через інший завантажувач не підтверджує ні конфігурацію цього клієнта, ні доступність проксі для цього запиту.