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