Resumiendo la publicación de blog de @Yihui: "Damas y caballeros, he dicho esto antes: require () es la forma incorrecta de cargar un paquete R; en su lugar, use library ()"
De Novo
1
@DanHall ... porque library()inmediatamente falla en voz alta, temprano y con un mensaje de error relevante (si el paquete no está instalado o no se pudo cargar), mientras require()que no genera un error, simplemente devuelve en silencio FALSO booleano que se descarta, y hace que el código falle más tarde y de forma más críptica con Error: object “bar” not found(digamos) la línea 175.
smci
1
@KonradRudolph: ¡Listo! Gracias por tus comentarios.
Marco
Respuestas:
87
Además del buen consejo ya dado, agregaría esto:
Probablemente sea mejor evitar el uso a require()menos que realmente esté usando el valor que devuelve, por ejemplo, en algún bucle de comprobación de errores como el que da thierry.
En la mayoría de los otros casos, es mejor usarlo library(), ya que esto dará un mensaje de error en el momento de cargar el paquete si el paquete no está disponible. require()simplemente fallará sin un error si el paquete no está allí. Este es el mejor momento para averiguar si el paquete necesita ser instalado (o tal vez ni siquiera existe porque se deletrea mal). Obtener comentarios de error temprano y en el momento relevante evitará posibles dolores de cabeza al rastrear por qué el código posterior falla cuando intenta usar rutinas de biblioteca
Sin embargo, de acuerdo con la documentación de ambas funciones (a la que se accede colocando un ?antes del nombre de la función y presionando enter), requirese usa dentro de las funciones, ya que genera una advertencia y continúa si no se encuentra el paquete, mientras libraryque arrojará un error.
#richiemorrisroe: Gracias. ¿Significa que si cargo los paquetes que necesito al comienzo de mi código R, no importa cuál elija?
Marco
66
siempre que no esté cargando paquetes dentro de una función, realmente no hay diferencia. Cargué todos mis paquetes usando require, y no supe cuál era la diferencia hasta que leí la ayuda después de ver su pregunta.
richiemorrisroe
45
La otra razón que uso requirees que me impide referirme a los paquetes como librariesuna práctica que impulsa a los R-cognoscenti por la pared. El libraryes la ubicación del directorio donde se encuentran los paquetes.
IRTFM
22
Tienen diferencias muy relevantes. No lo use require, a menos que verifique el valor de retorno (y en ese caso generalmente hay mejores alternativas, por ejemplo loadNamespace).
Konrad Rudolph
256
Otro beneficio de require()es que devuelve un valor lógico por defecto. TRUEsi los paquetes están cargados, FALSEsi no lo está.
> test <- library("abc")
Error in library("abc"): there is no package called 'abc'> test
Error: object 'test' not found> test <- require("abc")
Loading required package: abc
Warning message:
In library(package, lib.loc = lib.loc, character.only =TRUE, logical.return =TRUE,:
there is no package called 'abc'> test[1]FALSE
Por lo tanto, puede usar require()en construcciones como la siguiente. Lo que es principalmente útil si desea distribuir su código a nuestra instalación de R donde los paquetes podrían no estar instalados.
if(require("lme4")){
print("lme4 is loaded correctly")}else{
print("trying to install lme4")
install.packages("lme4")if(require(lme4)){
print("lme4 installed and loaded")}else{
stop("could not install lme4")}}
Usted puede envolver require()y library()en el suppressPackageStartupMessages()que, además, mensajes de paquetes suprimir el inicio, y también utilizar los parámetros require(..., quietly=T, warn.conflicts=F)si es necesario para mantener la calma instalaciones.
En pocas palabras, esto se debe a que, cuando se usa require, su código puede producir resultados diferentes y erróneos, sin indicar un error . ¡Esto es raro pero no hipotético! Considere este código, que produce resultados diferentes dependiendo de si se puede cargar {dplyr}:
require(dplyr)
x = data.frame(y = seq(100))
y =1
filter(x, y ==1)
Esto puede conducir a resultados sutilmente incorrectos. Usar en librarylugar de requirearroja un error aquí, indicando claramente que algo está mal. Esto es bueno .
También dificulta la depuración de todas las demás fallas: si requireutiliza un paquete al comienzo de su secuencia de comandos y utiliza sus exportaciones en la línea 500, recibirá un mensaje de error "objeto 'foo' no encontrado" en la línea 500, en lugar de un error "no hay paquete llamado 'bla'".
El único caso de uso aceptable requirees cuando su valor de retorno se verifica de inmediato, como muestran algunas de las otras respuestas. Este es un patrón bastante común, pero incluso en estos casos es mejor (y recomendado, ver más abajo) separar la verificación de existencia y la carga del paquete.
Más técnicamente, en requirerealidad llama libraryinternamente (si el paquete ya no estaba adjunto, por lo requiretanto, realiza una verificación redundante, porque librarytambién verifica si el paquete ya estaba cargado). Aquí hay una implementación simplificada de requirepara ilustrar lo que hace:
Iba a señalar exactamente lo mismo, a menos que llame a TODAS las funciones con la sintaxis class::function, use library()para evitar precisamente eso.
Fantasma
19
?library
y tu verás:
library(package)y require(package)ambos cargan el paquete con el nombre
packagey lo ponen en la lista de búsqueda. requireestá diseñado para usarse dentro de otras funciones; vuelve FALSEy da una advertencia (en lugar de un error como lo library()hace por defecto) si el paquete no existe. Ambas funciones verifican y actualizan la lista de paquetes cargados actualmente y no vuelven a cargar un paquete que ya está cargado. (Si desea volver a cargar dicho paquete, llame detach(unload = TRUE)o
unloadNamespaceprimero.) Si desea cargar un paquete sin incluirlo en la lista de búsqueda, use requireNamespace.
Mi teoría inicial sobre la diferencia era que librarycarga los paquetes si ya está cargado o no, es decir, podría volver a cargar un paquete ya cargado, mientras que requiresolo verifica que esté cargado o lo carga si no lo está (por lo tanto, el uso en funciones que dependen de un determinado paquete). Sin embargo, la documentación refuta esto y declara explícitamente que ninguna de las funciones volverá a cargar un paquete ya cargado.
Aquí parece ser la diferencia en un paquete ya cargado. Si bien es cierto que tanto require como library no cargan el paquete. La biblioteca hace muchas otras cosas antes de verificar y salir.
Recomendaría eliminar "require" desde el principio de una función que se ejecuta 2mil veces de todos modos, pero si, por alguna razón, necesito mantenerla. requerir es técnicamente una verificación más rápida.
microbenchmark(req = require(microbenchmark), lib = library(microbenchmark),times =100000)
Unit: microseconds
expr min lq mean median uq max neval
req 3.6765.1816.5969685.6556.1779456.0061e+05
lib 17.19219.88727.30290720.85222.490255665.8811e+05
Yo diría que esta es una buena razón para arreglar la implementación library(ambas funciones, como se incluyen actualmente con R, son un gran desastre).
Konrad Rudolph
@KonradRudolph bien, si alguien va a arreglar la biblioteca, tal vez también puedan habilitar la carga por versión explícitamente y hacer que el archivo adjunto sea una opción de argumento
forma el
Sí, estoy totalmente de acuerdo, pero eso cambiaría la semántica, no solo el rendimiento. De todos modos, el control de versiones nunca funcionará con paquetes en R, desafortunadamente. Estoy trabajando en un reemplazo para esto (¡en serio!). En cuanto a adjuntar, puede usar loadNamespace, que carga un paquete y devuelve su espacio de nombres, sin adjuntarlo.
library()
inmediatamente falla en voz alta, temprano y con un mensaje de error relevante (si el paquete no está instalado o no se pudo cargar), mientrasrequire()
que no genera un error, simplemente devuelve en silencio FALSO booleano que se descarta, y hace que el código falle más tarde y de forma más críptica conError: object “bar” not found
(digamos) la línea 175.Respuestas:
Además del buen consejo ya dado, agregaría esto:
Probablemente sea mejor evitar el uso a
require()
menos que realmente esté usando el valor que devuelve, por ejemplo, en algún bucle de comprobación de errores como el que da thierry.En la mayoría de los otros casos, es mejor usarlo
library()
, ya que esto dará un mensaje de error en el momento de cargar el paquete si el paquete no está disponible.require()
simplemente fallará sin un error si el paquete no está allí. Este es el mejor momento para averiguar si el paquete necesita ser instalado (o tal vez ni siquiera existe porque se deletrea mal). Obtener comentarios de error temprano y en el momento relevante evitará posibles dolores de cabeza al rastrear por qué el código posterior falla cuando intenta usar rutinas de bibliotecafuente
No hay mucho de uno en el trabajo diario.
Sin embargo, de acuerdo con la documentación de ambas funciones (a la que se accede colocando un
?
antes del nombre de la función y presionando enter),require
se usa dentro de las funciones, ya que genera una advertencia y continúa si no se encuentra el paquete, mientraslibrary
que arrojará un error.fuente
require
es que me impide referirme a los paquetes comolibraries
una práctica que impulsa a los R-cognoscenti por la pared. Ellibrary
es la ubicación del directorio donde se encuentran los paquetes.require
, a menos que verifique el valor de retorno (y en ese caso generalmente hay mejores alternativas, por ejemploloadNamespace
).Otro beneficio de
require()
es que devuelve un valor lógico por defecto.TRUE
si los paquetes están cargados,FALSE
si no lo está.Por lo tanto, puede usar
require()
en construcciones como la siguiente. Lo que es principalmente útil si desea distribuir su código a nuestra instalación de R donde los paquetes podrían no estar instalados.fuente
Puede usarlo
require()
si desea instalar paquetes si y solo si es necesario, como:Para múltiples paquetes puedes usar
Consejos profesionales:
Cuando se usa dentro del script, puede evitar una pantalla de diálogo especificando el
repos
parámetro deinstall.packages()
, comoUsted puede envolver
require()
ylibrary()
en elsuppressPackageStartupMessages()
que, además, mensajes de paquetes suprimir el inicio, y también utilizar los parámetrosrequire(..., quietly=T, warn.conflicts=F)
si es necesario para mantener la calma instalaciones.fuente
Siempre uso
library
. Nunca 1 usorequire
.( 1 Casi nunca. Quizás .)
En pocas palabras, esto se debe a que, cuando se usa
require
, su código puede producir resultados diferentes y erróneos, sin indicar un error . ¡Esto es raro pero no hipotético! Considere este código, que produce resultados diferentes dependiendo de si se puede cargar {dplyr}:Esto puede conducir a resultados sutilmente incorrectos. Usar en
library
lugar derequire
arroja un error aquí, indicando claramente que algo está mal. Esto es bueno .También dificulta la depuración de todas las demás fallas: si
require
utiliza un paquete al comienzo de su secuencia de comandos y utiliza sus exportaciones en la línea 500, recibirá un mensaje de error "objeto 'foo' no encontrado" en la línea 500, en lugar de un error "no hay paquete llamado 'bla'".El único caso de uso aceptable
require
es cuando su valor de retorno se verifica de inmediato, como muestran algunas de las otras respuestas. Este es un patrón bastante común, pero incluso en estos casos es mejor (y recomendado, ver más abajo) separar la verificación de existencia y la carga del paquete.Más técnicamente, en
require
realidad llamalibrary
internamente (si el paquete ya no estaba adjunto, por lorequire
tanto, realiza una verificación redundante, porquelibrary
también verifica si el paquete ya estaba cargado). Aquí hay una implementación simplificada derequire
para ilustrar lo que hace:Los desarrolladores experimentados de R están de acuerdo:
Yihui Xie , autor de {knitr}, {bookdown} y muchos otros paquetes dice :
Hadley Wickham , autor de paquetes R más populares que nadie, dice
fuente
class::function
, uselibrary()
para evitar precisamente eso.y tu verás:
fuente
Mi teoría inicial sobre la diferencia era que
library
carga los paquetes si ya está cargado o no, es decir, podría volver a cargar un paquete ya cargado, mientras querequire
solo verifica que esté cargado o lo carga si no lo está (por lo tanto, el uso en funciones que dependen de un determinado paquete). Sin embargo, la documentación refuta esto y declara explícitamente que ninguna de las funciones volverá a cargar un paquete ya cargado.fuente
Aquí parece ser la diferencia en un paquete ya cargado. Si bien es cierto que tanto require como library no cargan el paquete. La biblioteca hace muchas otras cosas antes de verificar y salir.
Recomendaría eliminar "require" desde el principio de una función que se ejecuta 2mil veces de todos modos, pero si, por alguna razón, necesito mantenerla. requerir es técnicamente una verificación más rápida.
fuente
library
(ambas funciones, como se incluyen actualmente con R, son un gran desastre).loadNamespace
, que carga un paquete y devuelve su espacio de nombres, sin adjuntarlo.