Ajustes de proxy en R: descargas de paquetes frente a solicitudes a la API
Siga el entorno de la sesión de R y el cliente HTTP que un paquete usa realmente, en lugar de combinar recetas de proxy incompatibles de versiones antiguas de R.
Si R puede instalar un paquete pero ese paquete no puede llegar a su API, compare los dos clientes de solicitudes. download.file(), RCurl y la propia capa HTTP de un paquete no tienen por qué leer las mismas opciones.
Revise las entradas de la sesión en ejecución
Un programa lanzado desde un terminal hereda el entorno de ese terminal. Un acceso directo del escritorio o un IDE que ya se ejecuta pueden tener valores distintos. El archivo de entorno de inicio de R adecuado puede contener:
http_proxy=http://proxy.example:8080
https_proxy=http://proxy.example:8080Son entradas de archivo de entorno con un punto de conexión de ejemplo. Para solicitudes públicas a paquetes o a la API permitidas a través de intermediarios públicos, la lista de proxies HTTP ofrece candidatos para esos valores. Expresiones de R como options(download.file.method = "libcurl") pertenecen al código R, no a .Renviron. Colocar el ajuste que parece correcto en el formato equivocado lo deja sin usar.
Identifique el archivo de inicio que seleccionan las reglas de R de sitio/usuario, entorno y directorio de trabajo. Un archivo local del proyecto puede explicar una diferencia entre dos proyectos en el mismo IDE. Cambie el archivo previsto y reinicie la sesión correspondiente; editarlo no actualiza el proceso que ya se ejecuta.
Siga la solicitud del paquete que falla
Identifique el método de descarga o la implementación HTTP real. Un ejecutable curl externo, el método libcurl de R y RCurl son consumidores distintos con sus propias entradas admitidas. Compare el mismo destino a través del paquete que falla, con los secretos ocultos.
Mantenga las recetas ajustadas a esa implementación y a la versión de R. El consejo antiguo de Windows --internet2 describe un comportamiento histórico. Conserve también el esquema de transporte del verdadero receptor de proxy: un destino HTTPS todavía puede usar un punto de conexión de proxy HTTP. Una instalación correcta mediante otro descargador no establece ni la configuración de este cliente ni la disponibilidad del proxy para esta solicitud.