Migliore spiegazione di quando utilizzare le importazioni / dipendenze

Il manuale " Scrivere estensioni R " fornisce le seguenti indicazioni su quando utilizzare le importazioni o dipende:

Le regole generali sono

• I pacchetti il ​​cui spazio dei nomi è necessario solo per caricare il pacchetto utilizzando la libreria (pkgname) devono essere elencati nel campo "Importazioni" e non nel campo "Dipende".
• I pacchetti che devono essere collegati per caricare correttamente il pacchetto utilizzando la libreria (pkgname) devono essere elencati solo nel campo "Dipende".

Qualcuno può fornire un po 'più di chiarezza su questo? Come faccio a sapere se il mio pacchetto necessita solo di spazi dei nomi caricati rispetto a quando ho bisogno di un pacchetto da allegare? Quali sono esempi di entrambi? Penso che il pacchetto tipico sia solo una raccolta di funzioni che a volte chiamano funzioni in altri pacchetti (in cui un po 'di lavoro è già stato codificato). Questo scenario 1 o 2 è sopra?

modificare

Ho scritto un post sul blog con una sezione su questo argomento specifico (cercare "Imports v Depends"). La grafica rende molto più facile da capire.

"Imports"è più sicuro di "Depends"(e rende anche un pacchetto usandolo un "cittadino migliore" rispetto ad altri pacchetti che usano "Depends").

Una "Depends"direttiva tenta di garantire la disponibilità di una funzione di un altro pacchetto collegando l'altro pacchetto al percorso di ricerca principale (ovvero l'elenco degli ambienti restituiti da search()). Questa strategia può tuttavia essere contrastata se un altro pacchetto, caricato in un secondo momento, inserisce una funzione con nome identico in precedenza sul percorso di ricerca. Chambers ( in SoDA ) usa l'esempio della funzione "gam", che si trova in entrambi i pacchetti game mgcv. Se fossero stati caricati altri due pacchetti, uno a seconda game uno a seconda mgcv, la funzione trovata dalle chiamate gam()dipenderebbe dall'ordine in cui erano collegati quei due pacchetti. Non bene.

Una "Imports"direttiva dovrebbe essere utilizzata per qualsiasi pacchetto di supporto le cui funzioni devono essere inserite <imports:packageName>(ricercate immediatamente dopo <namespace:packageName>), anziché sul normale percorso di ricerca. Se uno dei pacchetti nell'esempio sopra usasse il "Imports"meccanismo (che richiede anche importo importFromdirettive nel NAMESPACEfile), le cose sarebbero migliorate in due modi. (1) Il pacchetto otterrebbe esso stesso il controllo su quale mgcvfunzione viene utilizzata. (2) Mantenendo il percorso di ricerca principale libero dagli oggetti importati, non si spezzerebbe nemmeno potenzialmente la dipendenza dell'altro pacchetto dall'altra mgcvfunzione.

Questo è il motivo per cui l'utilizzo degli spazi dei nomi è una buona pratica, perché ora è applicato da CRAN e (in particolare) perché l'uso "Imports"è più sicuro dell'uso "Depends".

Modificato per aggiungere un avvertimento importante:

V'è un'eccezione, purtroppo, comune alla consigli di cui sopra: se il pacchetto si basa su un pacchetto che si da un altro pacchetto , il pacchetto sarà probabilmente necessario collegare con una direttiva.A"Depends"BA"Depends

Questo perché le funzioni nel pacchetto Asono state scritte con l'aspettativa che il pacchetto Be le sue funzioni siano associate al search()percorso .

Una "Depends"direttiva caricherà e allegherà il pacchetto A, a quel punto Ala "Depends"direttiva del pacchetto stesso , in una reazione a catena, causerà Banche il caricamento e il collegamento del pacchetto . Le funzioni nel pacchetto Asaranno quindi in grado di trovare le funzioni nel pacchetto Bsu cui si basano.

Una "Imports"direttiva caricherà ma non allegherà il pacchetto Ae non caricherà né alleggerà il pacchetto B. ( "Imports", Dopo tutto, si aspetta che gli scrittori del pacchetto utilizzano il meccanismo di namespace, e quel pacchetto Asaranno utilizzare "Imports"per puntare a qualsiasi funzioni Bche hanno bisogno di accedere a.) Chiama per le funzioni di tutte le funzioni in pacchetto Ache si basano sulle funzioni nella confezione Bvolontà di conseguenza fallire.

Le uniche due soluzioni sono:

1. Chiedi al tuo pacchetto di allegare il pacchetto Ausando una "Depends"direttiva.
2. Meglio a lungo termine, contattare il manutentore del pacchetto Ae chiedere loro di fare un lavoro più attento nel costruire il proprio spazio dei nomi (nelle parole di Martin Morgan in questa risposta correlata ).

Hadley Wickham fornisce una semplice spiegazione ( http://r-pkgs.had.co.nz/namespace.html ):

Elencare un pacchetto in uno Dependso entrambi Importsgarantisce che sia installato quando necessario. La differenza principale è che dove Importssolo carica il pacchetto, lo Dependsallega. Non ci sono altre differenze. [...]

A meno che non ci sia una buona ragione altrimenti, dovresti sempre elencare i pacchetti in Importsno Depends. Questo perché un buon pacchetto è autonomo e minimizza le modifiche all'ambiente globale (incluso il percorso di ricerca). L'unica eccezione è se il pacchetto è progettato per essere utilizzato insieme a un altro pacchetto. Ad esempio, il pacchetto analogico si basa su vegan. Non è utile senza vegan, quindi ha vegan Dependsinvece di Imports. Allo stesso modo, ggplot2 dovrebbe davvero dipendere dalle scale, piuttosto che importarlo.

Chambers in SfDA dice di usare 'Import' quando questo pacchetto usa un meccanismo 'namespace' e dato che ora tutti i pacchetti devono averli, allora la risposta potrebbe essere sempre usare 'Import'. In passato i pacchetti avrebbero potuto essere caricati senza effettivamente avere spazi dei nomi e in quel caso avresti dovuto usare Depends.

Ecco una semplice domanda per aiutarti a decidere quale utilizzare:

Il tuo pacchetto richiede all'utente finale di avere accesso diretto alle funzioni di un altro pacchetto?

• NO -> Importazioni (risposta più comune)
• SÌ -> Dipende

L'unica volta che dovresti usare "Dipende" è quando il tuo pacchetto è un componente aggiuntivo o un compagno di un altro pacchetto, in cui l'utente finale utilizzerà le funzioni sia del pacchetto sia del pacchetto "Dipende" nel loro codice. Se l'utente finale si interfaccia solo con le tue funzioni e l'altro pacchetto farà il lavoro solo dietro le quinte, usa invece "Imports".

L'avvertenza a questo è che se aggiungi un pacchetto a "Import", come di solito dovresti, il tuo codice dovrà fare riferimento alle funzioni di quel pacchetto, usando la sintassi completa dello spazio dei nomi, ad esempio dplyr::mutate(), anziché solo mutate(). Rende il codice un po 'più scomodo da leggere, ma è un piccolo prezzo da pagare per una migliore igiene del pacchetto.