On 26/10/2016 5:52 AM, Martin Maechler wrote:
Duncan Murdoch <murdoch.dun...@gmail.com>
on Mon, 24 Oct 2016 14:54:16 -0400 writes:
> On 24/10/2016 1:51 PM, Kevin Ushey wrote:
>> Hi R-devel,
>>
>> One of the more common issues that new R users see, and become stumped
>> by, is error messages during package load of the form:
>>
>> > library(ggplot2)
>> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
>> versionCheck = vI[[j]]) :
>> there is no package called 'Rcpp'
>> Error: package or namespace load failed for 'ggplot2'
>>
>> Typically, error messages of this form are caused simply by one or
>> more dependent packages (in this case, 'Rcpp') not being installed or
>> available on the current library paths. (A side question, which I do
>> not know the answer to, is how users get themselves into this state.)
> I think one way to get here is to be running with several libraries.
> You install ggplot2 while Rcpp is available, but in a different part of
> the .libPaths list, then in a later session try to use it with a
> different .libPaths setting.
>>
>> I believe it would be helpful for new users if the error message
>> reported here was a bit more direct, e.g.
>>
>> > library(ggplot2)
>> Error: 'ggplot2' depends on package 'Rcpp', but 'Rcpp' is not installed
>> consider installing 'Rcpp' with install.packages("Rcpp")
> The risk with this message is that Rcpp may really be installed, but
> it's just not currently on .libPaths. Detecting that situation and
> reporting on it looks like it would be relatively hard: it would mean
> the ggplot2 installation needs to record where it found all
> dependencies, and if at some later time it doesn't find one, see if that
> location still exists and would still work (in which case the message
> should suggest modifying .libPaths). I think that's too much work.
> Even a simple change like
> Error: 'ggplot2' depends on package 'Rcpp', but 'Rcpp' was not found
> might not be easy (which function knows both names?)
> However, if you want to suggest a patch to implement this,
> I would take a look.
I woul want to take a look, even before that. Our current error
handling here should be revised, I think :
If you've got the time to do that, please do so. My message really
meant "I have too much on my plate right now to develop a patch, but
this is important enough that I would evaluate one that you produced."
I think my "full plate" status is going to last until the end of the
year; after that I may have some more free time.
Duncan Murdoch
For library() the user sees *two* error messages: In my "setup"
((where I did fiddle with .libPaths() to provoke the error,
exactly as Duncan mentioned)), I have
library(ggplot2)
1. >> Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck =
vI[[i]]) :
there is no package called ‘gtable’
2. >> Error: package or namespace load failed for ‘ggplot2’
and together they at least give a good clue to the user (yes,
not easy enough for the beginner, I agree).
However, because the above is already a kludge (only one of the
two error messages is part of the error that is signalled !!!),
the situation is even worse if the user (or her code) uses require():
require(ggplot2)
Loading required package: ggplot2
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
there is no package called ‘gtable’
Only the 2nd of library()'s "Error" messages is transfered to require()
[or any other caller of library() !]
and that is in itself very unsatisfactory.
>> In other words, it might be helpful to avoid printing the
>> 'loadNamespace()' call on error (since it's mostly just scary /
>> uninformative), and check up-front that the package is installed
>> before attempting to call 'loadNamespace()'.
well, yes, one should not use try() there, but tryCatch() anyway :
try() is a wrapper around tryCatch() and I agree the error
message should not be printed which try() *does* by default, but
should be *combined* with the "2nd one" to one error.. which
then also is automatically "transfered" to require() or another caller.
There is a small problem for producing a really nice error
message : It is *wrong* to assume we can easily use sub() or
similar to get the dependecy package name ('gtable' or 'Rcpp' in
the above examples) from the error message :
The error message may be and often is translated {{apart from the
"Error in " of the first error message which is never
translated, it seems, but that is different issue(buglet) }} :
a) French:
Sys.setenv("LANGUAGE"="fr"); Sys.setlocale("LC_MESSAGES", "fr_FR.UTF-8")
library(ggplot2)
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
aucun package nommé ‘gtable’ n'est trouvé
Erreur : le chargement du package ou de l'espace de noms a échoué pour ‘ggplot2’
b) German:
Sys.setenv("LANGUAGE"="de"); Sys.setlocale("LC_MESSAGES", "de_CH.UTF-8")
[1] "de_CH.UTF-8"
library(ggplot2)
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
es gibt kein Paket namens ‘gtable’
Fehler: Laden von Paket oder Namensraum für ‘ggplot2’ fehlgeschlagen
c) Japanase :
Sys.setenv("LANGUAGE"="ja"); Sys.setlocale("LC_MESSAGES", "ja_JP.UTF-8")
[1] "ja_JP.UTF-8"
library(ggplot2)
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
‘gtable’ という名前のパッケージはありません
エラー: ‘ggplot2’ に対するパッケージもしくは名前空間のロードが失敗しました
We could try to look for the sQuote(.)'d package name
independently of the translation of the error message and use
that in the "merged" error message.
Martin
>> I'm sure a number of
>> novice users will still just throw their hands up in the air and say
>> "I don't know what to do", but I think this would help steer a number
>> of users in the right direction.
>>
>> (The prescription to suggest installing a package from CRAN if
>> available might be a step too far, but I think making it more clear
>> that the error is due to a missing dependent package would help.)
>>
>> Any thoughts?
>> Kevin
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
