Jak zarządzać wieloma lokalizacjami pakietów (folderami) w R?

Question

Zanim przejdę do wersji R-2.14, chcę wykorzystać okazję do zracjonalizowania struktury folderów zainstalowanych pakietów.

W tej chwili używam domyślnego R, tj. Wszystkie nowe zainstalowane pakiety trafiają do R_LIBS_USER. Jednak naprawdę rozróżniam dwie klasy pakietów:

• Pakiety, których wielokrotnie używam do wykonania mojej pracy, np. plyr, data.table itp
• pakiecie zainstalować tylko eksperymentować z (często powtórzyć pytanie lub odpowiedzieć na StackOverflow)

Od install.packages oferuje jedną z opcji, aby określić lib argumentu, to wyraźnie to możliwe.

Czy istnieje łatwy sposób na zarządzanie lokalizacjami pakietów, np. tworząc pewne sensowne ustawienia/wrappery w .RProfile lub RProfile.Site?

Answer 1

Doskonały pakiet Hadleya devtools zapewnia funkcję dev_mode.
http://www.inside-r.org/packages/cran/devtools/docs/dev_mode

Tutaj można znaleźć wykorzystanie na przykład: https://gist.github.com/1150934

Zasadniczo

dev_mode(TRUE, path = "anywhere-you-want-to-install") 
install.packages("anything-that-you-want-to-install") 

jest skutecznym sposobem.

Answer 2

Istnieje wiele opcji. Pierwszą rzeczą, którą zrobiłem, było zaadaptowanie mojego pliku Rprofile.site w celu zawarcia poniższego wiersza, dzięki czemu domyślna ścieżka do biblioteki jest katalogiem niewymienionym w mojej instalacji R.

.libPaths(c("D:/R/Library",.libPaths())) 

To sprawia, że ​​D:/R/Library jest moją domyślną ścieżką bez utraty innych ścieżek. Możesz dodać dwie ścieżki do tej, na przykład D:/R/Library/Work i D:/R/Library/Test. Ten, który jest umieszczony na pierwszym miejscu, jest domyślny, jeśli nie określisz lib w install.packages().

Następnie można przypisać dwie zmienne do pliku .Rprofile.site. Te są przypisane w podstawowej przestrzeni nazw i dlatego zawsze są dostępne i nie są usuwane przez ls(). Coś jak

.libwork <- 'D:/R/Library/Work' 
.libtest <- 'D:/R/Library/Test' 

który pozwala na zainstalowanie pakietów jak:

install.packages('aPackage',lib=.libwork) 

Istnieją też inne opcje, jak sądzę, ale to jak będę toczyć.

Answer 3

Powinieneś być w stanie określić kilka ścieżek/drzew bibliotek za pomocą rozdzielonej dwukropkami listy ścieżek w zmiennej środowiskowej R_LIBS. Nie mogłem tego zrobić niezawodnie na R 2.13.1-poprawka - to zawsze ma pierwszy wpis. Mam R_LIBS i R_LIBS_USER, aby działały niezawodnie na moim komputerze - zwykle ustawiam tylko ten pierwszy.

.libPaths() może dodawać nowe ścieżki do zestawu przeszukiwanych drzewek bibliotecznych. Właśnie dodałem odpowiednie wywołania do .libPaths(new) w moim .Rprofile, aby dodać odpowiednie drzewa dla każdej sesji. Następnie możesz wybrać miejsce instalacji pakietów w czasie instalacji - tzn. Którego drzewa użyć.

Answer 4

Aby odpowiedzieć, muszę podać trochę kontekstu.

Dla celów odtwarzalności, próbuję pisać scenariusze, w tym całą konfigurację R. Mam skrypt "initializeR.r", który między innymi instaluje pakiety, a ja przygotowałem pakiety w pakietach, takich jak te związane z cacheingiem, te związane z wizualizacją, próbkowaniem, statystykami przestrzennymi itp. - moje własne małe widoki zadań, jeśli chcesz.

Na przykład, oto fragment:

# Profiling & testing 
Packages$CodingTools = c("codetools","debug", "profr","proftools","RUnit") 

łączę kilka wiązek do „poważnej” pakietów (lub podstawowej) listy i inni idą na „wtórnym” listy. Na pewno zainstaluję wszystko na głównej liście - są one potrzebne, aby mieć rozsądne środowisko R, używać własnych skryptów, funkcji i pakietów itp. (Btw, niektóre pakiety są przypisane do wielu pakietów, ale tylko kilka; Usuwam duplikat przed przetworzeniem zbiorczej listy.)

Następnie określę domyślną bibliotekę domyślną dla platformy i zainstaluję ją tam. Ta możliwość jest jednak rozszerzalna i ten pomysł można rozszerzyć o opcjonalne lokalizacje dla każdego pakietu pakietów (lub pakietu): wystarczy mapować z nazwy pakietu, np. "CodingTools" do unikalnego katalogu (ścieżka biblioteki), powiedz "D:/R/Library/CodingTools". Można to zrobić w skrypcie inicjalizacyjnym, z opcjami domyślnymi dla pasujących list, lub lokalizacje mogą być przechowywane gdzie indziej, takie jak tablica asocjacyjna, JSON lub baza danych.

Jak powiedzieli inni, domyślne ścieżki biblioteki muszą zostać przekazane R. Można to zrobić na stronie .RProfile.site. W moim przypadku mam inny skrypt, który jest używany do zainicjowania instancji R, tak jakbym chciał. Próbuję unikać zewnętrznych plików parametrów, które są odczytywane przez R (na przykład .Rprofile), a zamiast tego wszystkie inicjalizacje są wywoływane przez funkcje w moim własnym pakiecie (chociaż parametry są nadal zewnętrzne). To ułatwia mi debugowanie i odtwarzanie mojej pracy. Tak więc ścieżki mojej biblioteki mogą być zawarte w tym samym rodzaju JSON, w którym określone są moje lokalizacje plików danych.

Osobiście chcę odejść od definiowania pakietów wewnątrz skryptu i zamiast tego używać JSON, ponieważ mogę łatwiej tworzyć różne pliki JSON dla różnych konfiguracji konfiguracji. Już to robię dla większości innych celów powtarzalnej pracy.