[Bioc-devel] Dependency on devtools in biocLite()

Martin Morgan martin.morgan at roswellpark.org
Sat Jan 14 09:43:32 CET 2017


On 01/13/2017 06:29 PM, Andrzej Oleś wrote:
> Dear all,
>
> it's great that for some time now `biocLite()` also resolves package
> dependencies for GitHub hosted packages. However, as this functionality
> depends on devtools, an attempt to install a GitHub package when devtools
> is not installed results in an error
>
>> library(BiocInstaller)
>> biocLite("aoles/RBioFormats")
> BioC_mirror: https://bioconductor.org
> Using Bioconductor 3.4 (BiocInstaller 1.24.0), R 3.3.2 (2016-10-31).
> Error: package 'devtools' not available: there is no package called
> ‘devtools’
>
> If this is the case, one would typically need to first install devtools,
> and rerun the biocLite command. I was wondering whether it would make sense
> to modify the behavior such that before attempting to call
> `devtools::install` in
>
> https://github.com/Bioconductor-mirror/BiocInstaller/blob/
> 9965cc72d009bfcae6776a02e5abb94cbd5dd109/R/biocLite.R#L48
>
> first check for devtools availability and try to automatically install it
> if missing (maybe by prompting the user). What do you think?

I'm not a fan of automatic package installation, e.g., because a user 
(e.g., me) might have a configuration of library paths that they are 
trying to maintain. This leads me down the slippery slope of not wanting 
to offer to install a package, either, because again the offer would be 
too narrow, some users (again, e.g., me) will reject it and prefer to 
have control, and so why not have a standard work flow -- user fixes 
package installation to their satisfaction and tries again -- rather 
than a conditional work flow.

On the other hand the error message "package 'devtools' not available: 
there is no package called 'devtools'" seems to be poorly worded -- 
there is a package devtools, and it is available, just not in the 
current installation. One could try to provide a better message, but one 
would rather the message were improved upstream so all similar 
situations were handled the same; at least this way the user has to 
learn only once what the message means.

Martin

>
> Cheers,
> Andrzej
>
> 	[[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


This email message may contain legally privileged and/or...{{dropped:2}}



More information about the Bioc-devel mailing list