Rimuovere (o escludere) una funzione dal pacchetto importato

Esiste un modo per escludere una funzione da un pacchetto importato. Ad esempio, uso quasi tutto il dplyr ma recentemente, hanno aggiunto una nuova funzione chiamata recode che sovrascrive una funzione che ho da un pacchetto proprietario (che non posso apportare modifiche).Rimuovere (o escludere) una funzione dal pacchetto importato

Esiste un modo per escludere la funzione s3 dallo spazio dei nomi in modo che visualizzi solo la funzione dal mio pacchetto e ignori quella da dplyr.

Sono consapevole che siamo in grado di importare le funzioni una tantum da un pacchetto con facilità, ma in questo caso, sto cercando di escludere - solo uno.

fonte

2016-07-10 Brandon Bertelsen

Se si carica il pacchetto che volete dopo 'dplyr' non dovrebbe la tua funzione desiderata maschera la 'dplyr'? –

Ho provato a farlo ma non funziona perché il pacchetto proprietario non esporta correttamente le sue funzioni. –

Capisco. Quindi, stavo per suggerire di biforcare dplyr su GitHub e rimuovere la funzione che non vuoi, ma se dici che l'hanno aggiunta di recente, perché non usare solo la versione più recente che non ha avuto 'recode'? –

R 3.3.0 o successiva ora supportano "import all but x,y,z from foo" statements:

\item The \code{import()} namespace directive now accepts an 
    argument \code{except} which names symbols to exclude from the 
    imports. The \code{except} expression should evaluate to a 
    character vector (after substituting symbols for strings). See 
    Writing R Extensions.

Mi pare che è esattamente ciò che si vuole qui, e vuole la maggior parte delle persone vogliono che non hanno intenzione di avere dplyr clobber sulle funzioni da il pacchetto di statistiche incluso con R come filter o lag.

cura sulla base di discussione in seguito nei commenti: esempio di utilizzo

esempio nel file di NAMESPACE per Section 1.5.1 of WRE è la seguente:

import(dplyr, except = c(recode, lag, filter))

fonte

2016-07-10 21:40:32

questo è generalmente estremamente utile ma potrebbe non essere utile all'OP, che sta usando un pacchetto proprietario le cui dichiarazioni "Imports:" apparentemente non possono cambiare ...? –

È l'effetto collaterale 'Imports:' of 'dplyr' di cui si lamenta e ha il controllo. Penso che questo sia in effetti quello che sta cercando. Ho pensato che "cannotTouchProprietaryPackage" sia importato intero, come lo sono _parts_ di 'dplyr'. –

@DirkEddelbuettel hai visto un esempio di utilizzo documentato da qualche parte? –

Utilizzare la versione Hack-R di dplyr invece della versione Hadley. Dato che l'ho creato negli ultimi 2 minuti, puoi anche creare facilmente la tua versione.

require(devtools) 
install_github("hack-r/dplyr") 
require(dplyr)

Tutto quello che ho fatto è stato forchetta, aprire il progetto in RStudio tramite il controllo di versione, rimuovere recode, commettere, e spingerlo di nuovo al mio GitHub.

fonte

2016-07-10 20:50:17

Certo, ma basta creare una foglia vecchia nel grande albero dei pacchetti R. Questo non ti ha portato aggiornamenti ecc. Pp. –

@DirkEddelbuettel Lo so, ma qual è il tuo punto? 1. Quanto ci vuole per aggiornare? 30 - 60 secondi? 2. Hai davvero bisogno di aggiornamenti per 'dplyr'? La maggior parte delle persone che conosco congela intenzionalmente la versione dei pacchetti che stanno usando nel codice di produzione (e il problema con il PO è un buon esempio del perché). –

Prendo sul serio il funzionamento di R, CRAN, BioC, ... ecosystem * very * seriamente, come faccio per es. Debian e Ubuntu e i loro pacchetti oltre 20k. Sei molto libero di avere un'opinione diversa, ma ciò non impedirà a me stesso (e agli altri) di pensare che tu abbia torto. Non c'è niente di sbagliato in "hacking per hacking sake", ma mi preoccupo dei sistemi di produzione adeguati, così come Brandon per il suo cliente. –

L'altra alternativa sarebbe quella di utilizzare

recode <- SILLY_PROPRIETARY_PACKAGENAME::recode

alla testa del codice (con un commento esplicativo) per creare una copia di recode nello spazio di lavoro globale (che dovrebbe poi mascherare la versione da dplyr) . Ciò potrebbe impedire future confusioni quando si consegna il codice a qualcuno che ha installato lo stock dplyr, anziché la propria versione compromessa personalmente.

fonte

2016-07-10 21:02:11

Lo sveglierò, ma sembra che manchi il divertimento e l'eccitazione dell'hacking;) –

Questo in realtà non funziona per me. In qualche modo, 'recode.numeric' da' dplyr' viene ancora inviato prima della mia generica funzione 'recode' nell'ambiente globale. –

@BrandonBertelsen ora stiamo diventando hacky, ma potresti aggiungere 'SILLY_PROPRIETARY_PACKAGE ::: recode.numeric' come sopra. forse usa una chiamata 'eval' con quello che impari dai' metodi' per automatizzarla se funziona – MichaelChirico

Rimuovere (o escludere) una funzione dal pacchetto importato

risposta

Problemi correlati