Thanks Martin! I see your point - then I suggest that at least the call to `devtools::install` is guarded by a customized more informative error massage, something along the lines:
Package 'devtools' missing: please install it (e.g., by a call to `install.packages('devtools')`) and re-run your biocLite command. Cheers, Andrzej On Sat, Jan 14, 2017 at 9:43 AM, Martin Morgan < martin.mor...@roswellpark.org> wrote: > 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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> > > This email message may contain legally privileged and/or confidential > information. If you are not the intended recipient(s), or the employee or > agent responsible for the delivery of this message to the intended > recipient(s), you are hereby notified that any disclosure, copying, > distribution, or use of this email message is prohibited. If you have > received this message in error, please notify the sender immediately by > e-mail and delete this email message from your computer. Thank you. > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel