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

Martin Morgan martin.morgan at roswellpark.org
Thu Jan 19 08:08:12 CET 2017

On 01/17/2017 07:15 AM, Andrzej Oleś wrote:
> 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.

I've updated the error message in 1.25.3; thanks for the suggestion.


> Cheers,
> Andrzej
> On Sat, Jan 14, 2017 at 9:43 AM, Martin Morgan
> <martin.morgan at roswellpark.org <mailto:martin.morgan at 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/
>         <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 <mailto:Bioc-devel at r-project.org>
>         mailing list
>         https://stat.ethz.ch/mailman/listinfo/bioc-devel
>         <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.

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

More information about the Bioc-devel mailing list