improving the performance of install.packages

I believe introducing a backward compatible force=TRUE is a good
start, even if we're not ready for making force=FALSE the default at
this point.  It would help simplify quite-common instructions like

if (requireNamespace("BiocManager"))
   install.packages("BiocManager")
BiocManager::install(...)

to

install.packages("BiocManager", force=FALSE)
BiocManager::install(...)

and more so when installing lots of packages conditionally, e.g.

if (requireNamespace("foo")) install.packages("foo")
if (requireNamespace("bar")) install.packages("bar")
...

to

install.packages(c("foo", "bar", ...), force = FALSE)

Before deciding on making force=FALSE the new default, I think it
would be valuable to play the devil's advocate and explore and
identify all possible downsides of such a default, e.g. breaking
existing instructions, downstream package code that uses
install.packages() internally, and so on.

/Henrik

PS. Although the idea of having update.packages() install missing
packages is not bad, I don't think I'm a not a fan for the sole
purpose of risking installation instructions starting using
update.packages() instead, which will certainly confuse those who
don't know the history (think require() vs library()).

On Fri, Nov 8, 2019 at 3:11 PM Pages, Herve <hpages at fredhutch.org> wrote:

Hi Gabe,

Keeping track of where a package was installed from would be a nice
feature. However it wouldn't be as reliable as comparing hashes to
decide whether a package needs re-installation or not.

H.

On 11/8/19 12:37, Gabriel Becker wrote:

Hi Josh,

There are a few issues I can think of with this. The primary one is that
CRAN(/Bioconductor) is not the only place one can install packages from. I
might have version x.y.z of a package installed that was, at the time, a
development version I got from github, or installed locally, etc. Hell I
might have a later devel version but want the CRAN version. Not common,
sure, but wiill likely happen often enough that install.packages not doing
that for me when I tell it to is probably bad.

Currently (though there has been some discussion of changing this) packages
do not remember where they were installed from, so R wouldn't know if the
version you have is actually fully the same one on the repository you
pointed install.packages to or not.  If that were changed  and we knew that
we were getting the byte identical package from the actual same source, I
think this would be a nice addition, though without it I think it would be
right a high but not high enough proportion of the time.

R will build the package from source (depending on what OS you're using)

twice by default. This becomes especially burdensome when people are using
big packages (i.e. lots of depends) and someone has a script with:

install.packages("tidyverse")

...
... later on down the script
...
install.packages("dplyr")

I mean, IMHO and as I think Duncan was alluding to, that's straight up an
error by the script author. I think its a few of them, actually, but its at
least one. An understandable one, sure, but thats still what it is. Scripts
(which are meant to be run more than once, generally) usually shouldn't
really be calling install.packages in the first place, but if they do, they
should certainly not be installing umbrella packages and the packages they
bring with them separately.

Even having one vectorized call to install.packages where all the packages
are installed would prevent this issue, including in the case where the
user doesn't understand the purpose of the tidyverse package. Though the
installation would still occur every time the script was run.


The last thing to note is that there are at least 2 packages which provide
a function which does this already (install.load and remotes), so people
can get this functionality if they need it.


On Fri, Nov 8, 2019 at 11:56 AM Joshua Bradley <jgbradley1 at gmail.com> wrote:

I assumed this list is used to discuss proposals like this to the R
codebase. If I'm on the wrong list, please let me know.

This is the right place to discuss things like this. Thanks for starting
the conversation.

Best,
~G

       [[alternative HTML version deleted]]

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319