[Rd] improve 'package not installed' load errors?

Martin Maechler
Wed, 26 Oct 2016 09:52:55 -0000

>>>>> Duncan Murdoch <murdoch.duncan at 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 :

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