Настройки прокси в 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. Успешная установка через другой загрузчик не подтверждает ни конфигурацию этого клиента, ни доступность прокси для этого запроса.