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

Reply via email to