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.mor...@roswellpark.org <mailto: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/
<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 <mailto:Bioc-devel@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}}
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
