Jest to kontynuacja opublikowanej wcześniej wersji question. Podsumowując, piszę pakiet R o nazwie Slidify, który korzysta z wielu zewnętrznych bibliotek nie opartych na R. Moje wcześniejsze pytanie dotyczyło zarządzania zależnościami.R Pakiet z dużymi aktywami zewnętrznymi
Zaproponowano kilka rozwiązań, z których najbardziej atrakcyjnym rozwiązaniem było spakowanie zewnętrznych bibliotek jako innego pakietu R i uczynienie go zależnym od Slidify. Jest to strategia, po której następuje pakiet xlsx, który pakuje zależności java jako inny pakiet xlsxjars.
Alternatywą jest dostarczenie zewnętrznych bibliotek do pobrania i spakowanie funkcji install_libraries w Slidify, która automatycznie pobierze wymagane pliki i pobierze je do katalogu pakietów. Mogę również dodać funkcję update_libraries, która zostanie zaktualizowana, jeśli coś się zmieni.
Moje pytanie brzmi, czy są jakieś konkretne zalety wykonania tańca CRAN dla bibliotek zewnętrznych, które nie są oparte na R. Czy coś mi umyka?
Nie rób 'install_libraries' siekać. Używanie CRAN jako centralnego mechanizmu repo i dystrybucji jest preferowane: 'install.packages()' już istnieje, podobnie jak warianty aktualizacji itp. Poprzez wynalezienie nowego mechanizmu po prostu zejdziesz po śliskim zboczu nowych i niesprawdzonych błędów. Zasadniczo próbujesz wyobrazić sobie, co robi dystrybucja lub system taki jak Fink. Zbyt dużo złożoności. –
Dzię kujemy za pomocĘ ... @Dirk. Zewnętrzne biblioteki mają rozmiar 10 MB i kiedy czytałem dokumentację CRAN, powiedział coś, co utrzymywało rzeczy poniżej 5 MB. Rozumiem, że CRAN zapewnia prosty mechanizm i ma sens, aby go używać wszędzie, gdzie to możliwe. – Ramnath
Czy to Java, jak dla Xlxs i Weka? Wtedy pakiet słoików ma sens. W przeciwnym razie masz problem kompatybilności binarnej i może polegać na poleganiu na użytkowniku. –