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 <jgbradl...@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]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=XG4gVQKZam41YLfI3w8XRAu8s7f2I5jCppA45q6NBu0&s=cOXQGMA9Va3o9x1USGggzF82D1LtFQb2ALpLRLQs2k4&e= > -- 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: hpa...@fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel