Avoid re-installing packages that have been installed

[Yihui Xie]

Hi,

Sometimes I feel it is unnecessary and time-consuming to re-install a
package of a certain version that has been installed in the system or
user's library. For example, I really hate reinstalling packages like
XML/RCurl/stringi/... from source on Linux:
https://github.com/ramnathv/htmlwidgets/blob/gh-pages/packrat/packrat.lock
I wonder if it is possible for packrat to avoid installing such
packages if their required versions have already been installed, e.g.
I have installed XML 3.98-1.1 (via apt-get install r-cran-xml), and I
wish packrat could just use it, instead of downloading the source from
CRAN and compiling it from source.

In other words, I wish packrat is more about package versions than
rebuilding the whole universe unconditionally :)

Regards,
Yihui

[Kevin Ushey]

One thing that packrat has that attempts to make this possible is the 'external.packages' project option. The idea is that, for all packages listed in 'external.packages', packrat will attempt to load those from the user library rather than the local packrat library.

You could try e.g.

    packrat::opts$external.packages(c("XML", "RCurl", "stringi"))

Either way, this issue hallmarks some of the tension with packrat as a tool for reproducible project management, and a tool simply for package management (with less emphasis on reproducible).

[Yihui Xie]

Thanks, Kevin. It seems opts$external.packages can solve this
particular problem, but it may violate principles of reproducibility,
since there is no guarantee the versions of external packages are what
was specified in the packrat.lock file (or there is?). At the moment,
I don't mind reinstalling a package if the project author requires a
different version in the lock file. It is just that I don't want to
reinstall the same version. I guess there is a lot of redundancy by
reinstalling everything, and we don't necessarily lose reproducibility
by using some packages from the system's global R package libraries as
long as the version requirement is satisfied.

Regards,
Yihui

[Joe Cheng]

What would happen if we don't install a local copy of package X because the version we want is in the global library, and then later, the version in the global library is upgraded or downgraded?

Perhaps you'd be better served by enabling the packrat cache--it doesn't solve the problem of extra disk space being taken up, but at least the install should be super fast once the cache is primed.

--
You received this message because you are subscribed to the Google Groups "packrat-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packrat-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yihui Xie]

If the version of X in the global library has changed, I'm fine with
reinstalling the desired version specified in packrat.lock.

Personally I don't like locking down versions. I tend to continuously
test new versions as soon as they become available, and upgrade if I
don't find problems. I understand this sounds risky and is a bad idea
in certain cases. I think there are two approaches to reproducibility:
locking down the environment, or testing as we move forward. I cannot
tell which is uniformly better (both have pros and cons), but usually
my own preference is the latter.

Regards,
Yihui