> On 6/21/19 10:56 AM, Tierney, Luke wrote:
> [...]
> Something that would be useful and is being considered is having a
> mechanism for registering default condition handlers. This would allow
> the condition to be re-signaled with a custom class and then having
> a custom conditionMessage method is less likely to cause conflicts.
Is it correct that you are proposing something that allows us to do:
registerDefaultConditionHandlers(
packageStartupMessage = function(c) {
## Do something with condition 'c'
...
## Suppress futher processing
invokeRestart("muffleMessage")
}
)
at the core, which avoids having us to wrap up calls in
withCallingHandlers() at top-level calls, e.g.
> withCallingHandlers({
library("foobar"),
}, packageStartupMessage = function(c) {
## Do something with condition 'c'
...
## Suppress futher processing
invokeRestart("muffleMessage")
})
?
Then, if I read this correctly, I'd say, this would be a very useful
addition to base R. This will provide a core framework that opens up
for several neat extensions, e.g. the one that Marcel suggests - some
people prefer a message/warning on misspelled package names, while
others might want to see if it can be automatically installed, and so
on. And, it will (=should) be all in the hands of the end user to
control this, i.e. various packages should not override this similar
to how we don't expect them to override other personal R settings we
have.
With this in place, it's not hard to imagine a third-party package
that provides useful handlers that users can pick from, e.g.
buttlr::i_am_a("first_time_r_user")
to get extra information for some of the common warnings and errors,
which is in the same spirit as your idea on:
> [...] This would allow an IDE, for example, to provide a dialog for
> choosing the alternate package and retrying without the need to call
> library() again. [...]
I also think such a framework could replace some of the "legacy
handlers" we currently have in place, e.g. R options 'warn',
'warnPartialMatchArgs', '...', and even 'error', and give more
granular control over those use cases. For instance, instead of a
warning or a partial argument match, I might want to produce an error
unless it comes from one particular package, say, which is something
that is a bit tricky to do today.
/Henrik
PS. Somewhat related to this, standardizing muffling and signaling of
conditions could be worth looking into as well. For instance, being
able to resignal an error 'e' with a *generic* signalCondition(e)
instead of having to know that you should call stop(e) for 'error'
conditions and maybe another function if the error is of another
class.
On Fri, Jun 21, 2019 at 8:55 AM Marcel Ramos
<[email protected]> wrote:
>
> Hi Luke,
>
> Thank you for your response.
>
> On 6/21/19 10:56 AM, Tierney, Luke wrote:
>
> Thanks for the suggestion. However I don't think it is the right way
> to go. I also don't care for what install.packages() does. Signaling a
> warning and then an error means someone has to catch both the error
> and the warning, or suppress the warning, in order to handle the error
> programmatically.
>
> I do care for what install.packages() does because it's preferable
> to have consistency in the user interface.
>
> I see that the proposed patch does return both an error and a warning
> but as far as I understand it, library()'s main/intended use is interactive
> and
> there are other functions available for programmatic use cases.
>
>
>
> Now that library() signals a structured error there are other options.
> One possibility, at least as an interim, is to define a
> conditionMessage method, e.g. as
>
> conditionMessage.packageNotFoundError <- function(c) {
> lib.loc <- c$lib.loc
> msg <- c$message
> package <- c$package
> if(length(lib.loc)) {
> allpkgs <- .packages(TRUE, lib.loc)
> if (!is.na(w <- match(tolower(package), tolower(allpkgs)))) {
> msg2 <- sprintf("Perhaps you meant %s ?", sQuote(allpkgs[w]))
> return(paste(msg, msg2, sep = "\n"))
> }
> }
> msg
> }
>
> This is something you can do yourself, though it is generally not a
> good idea to define a method when you don't own either the generic or
> the class.
>
> Something that would be useful and is being considered is having a
> mechanism for registering default condition handlers. This would allow
> the condition to be re-signaled with a custom class and then having
> a custom conditionMessage method is less likely to cause conflicts.
>
> I'd argue that this is quite useful especially for new users and that creating
> condition handlers may involve more than what is needed for interactive use.
>
>
> Best,
>
> Marcel
>
>
>
> Also worth looking into is establishing a restart around the error
> signal. This would allow an IDE, for example, to provide a dialog for
> choosing the alternate package and retrying without the need to call
> library() again. This is currently done in loadNamespace() but not yet
> in library(). Can have downsides as well -- if the library() call is
> in a notebook, for example, then you do want to fix the call ... It
> is arguably more useful in loadNamespace since that can get called
> implicitly inside a longer computation that you don't necessarily want
> to start over.
>
> Best,
>
> luke
>
> On Fri, 21 Jun 2019, Marcel Ramos wrote:
>
>
>
> Dear R-core devs,
>
> I hope this email finds you well.
>
> Please see the proposed patch to R-devel below:
>
> Scenario:
>
> When loading a package using `library`, a package may not be found if the
> cases are not matching:
>
> ```
>
>
> library(ORG.Hs.eg.db)
>
>
> Error in library(ORG.Hs.eg.db) :
> there is no package called 'ORG.Hs.eg.db'
> ```
>
>
> Suggested Patch:
>
> Returns a message matching what `install.packages` returns in such situations:
>
> ```
>
>
> library("ORG.Hs.eg.db")
>
>
> Error in library("ORG.Hs.eg.db") :
> there is no package called 'ORG.Hs.eg.db'
> In addition: Warning message:
> Perhaps you meant 'org.Hs.eg.db' ?
> ```
>
> This patch will be helpful with 'fat-finger' typos. It will match a package
> called with `library` against installed packages.
>
>
> svn diff:
>
> Index: src/library/base/R/library.R
> ===================================================================
> --- src/library/base/R/library.R (revision 76727)
> +++ src/library/base/R/library.R (working copy)
> @@ -300,8 +300,13 @@
> pkgpath <- find.package(package, lib.loc, quiet = TRUE,
> verbose = verbose)
> if(length(pkgpath) == 0L) {
> - if(length(lib.loc) && !logical.return)
> + if(length(lib.loc) && !logical.return) {
> + allpkgs <- .packages(TRUE, lib.loc)
> + if (!is.na(w <- match(tolower(package),
> tolower(allpkgs))))
> + warning(sprintf("Perhaps you meant %s ?",
> + sQuote(allpkgs[w])), call. = FALSE, domain = NA)
> stop(packageNotFoundError(package, lib.loc, sys.call()))
> + }
> txt <- if(length(lib.loc))
> gettextf("there is no package called %s", sQuote(package))
> else
>
>
> Thank you!
>
> Best regards,
>
> Marcel
>
>
>
> --
> Marcel Ramos
> Bioconductor Core Team
> Roswell Park Comprehensive Care Center
> Dept. of Biostatistics & Bioinformatics
> Elm & Carlton Streets
> Buffalo, New York 14263
>
>
> 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]]
>
> ______________________________________________
> [email protected]<mailto:[email protected]> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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]]
>
> ______________________________________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
