[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.
Martin
>
>
> 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