Ho riscontrato questo problema alcune volte e non sono in grado di trovare alcuna soluzione tranne quella banale (vedi sotto).Metodo sicuro per l'aggiornamento dei pacchetti R: lo "scambio a caldo" è possibile?
Supponiamo che un computer stia eseguendo 2 o più istanze di R, a causa di 2+ utenti o 1 utente che esegue più processi e un'istanza esegue update.packages(). Ho avuto diverse volte in cui l'altra istanza può essere messa in difficoltà alla grande. I pacchetti in fase di aggiornamento non modificano la funzionalità in alcun modo che influisce sul calcolo, ma in qualche modo si pone un grosso problema.
La soluzione banale (Soluzione 0) è di terminare tutte le istanze di R mentre si esegue update.packages(). Questo ha 2 o più problemi. Primo, uno deve terminare le istanze R. Secondo, uno potrebbe non essere nemmeno in grado di identificare dove sono in esecuzione quelle istanze (vedere l'aggiornamento 1).
Supponendo che il comportamento del codice in esecuzione non cambierà (ad esempio, gli aggiornamenti dei pacchetti sono tutti vantaggiosi - risolvono solo bug, migliorano la velocità, riducono la RAM e concedono gli unicorni), c'è un modo per scambiare a caldo un nuova versione del pacchetto con minore impatto su altri processi?
Ho altre due soluzioni candidate, al di fuori della R:
Soluzione 1 è quello di utilizzare un percorso di libreria temporanea e quindi eliminare il vecchio vecchia biblioteca e spostare il nuovo al suo posto. Lo svantaggio di questo è che cancella + mosse può incorrere in un tempo durante il quale nulla è disponibile.
Soluzione 2 utilizza i collegamenti simbolici per puntare a una libreria (o una gerarchia di libreria) e sovrascrive semplicemente un collegamento simbolico con un puntatore a una nuova libreria in cui risiede il pacchetto aggiornato. Ciò sembra comportare anche meno tempi di inattività del pacchetto: il tempo impiegato dal sistema operativo per sovrascrivere un collegamento simbolico. Lo svantaggio di questo è che richiede molta più attenzione nella gestione dei collegamenti simbolici ed è specifico per la piattaforma.
Ho il sospetto che la soluzione # 1 potrebbe essere modificato per essere come # 2, con l'uso intelligente di .libPaths(), ma questo mi sembra uno ha bisogno di non chiamata update.packages() e invece scrivere un nuovo aggiornamento che trova i pacchetti obsoleti, installazioni li a una libreria temporanea e quindi aggiorna i percorsi della libreria. Il lato positivo di questo è che si potrebbe vincolare un processo esistente allo .libPaths() che aveva quando è stato avviato (cioè modificare i percorsi della libreria che R sa potrebbe non essere propagato a quelle istanze già in esecuzione, senza alcun intervento esplicito all'interno di quell'istanza).
Aggiornamento 1. Nello scenario di esempio, le due istanze R concorrenti si trovano sulla stessa macchina. Questo non è un requisito: per quanto riguarda gli aggiornamenti, se i due condividono le stesse librerie, cioè le stesse directory su un'unità condivisa, l'aggiornamento può ancora causare problemi, anche se l'altra istanza di R si trova su un'altra macchina . Quindi, uno potrebbe accidentalmente uccidere un processo R e nemmeno vederlo.
Si tratta di un punto importante. Sospetto che il problema di una libreria condivisa sia un problema tra i sistemi operativi. Per la maggior parte dell'uso, sono incline a credere che questo uccida l'idea di hotswapping. Il caso più stretto sarebbe per i pacchetti che non utilizzano librerie condivise esterne, ma non sono sicuro di come funzioni per i pacchetti interamente in R. – Iterator
Penso che la tua risposta schiaccerà il sogno di hotswapping in generale. Anche se ho un pacchetto R puro che mi piacerebbe fare il hotswap, non è una buona pratica presumere di poterlo fare. Vincent ha un risposta ragionevole per come si può fare il controllo delle versioni, piuttosto che lo scambio, che dovrò adattare un po ', ma è chiaro che questo è l'unico modo per aggirare i conflitti hai sottolineato. – Iterator