failure if pkgPath is not valid

[sgsokol]

For some obscure reason, a variable pkgPath is returned as character(0) in my unit tests run on R-devel (win10) under CMD check (in interactive session they run OK, as well as on R-3.6.1). Anyway, if this line:

Rcpp/R/Attributes.R

Line 964 in d6594ba

pkgPath <- find.package(package, NULL, quiet=TRUE)

returns character(0) the .linkingToIncludes() ends up with an error "argument is of length zero" in the line if (file.exists(pkgHeaderPath)) {. It would be great to add a test for length(pkgPath) and if it is zero, to stop with a meaningfull error message "package 'pkg' is not found" or alike.

[eddelbuettel]

I glanced at (my installed version of) find.package() from base R; out <- character() is the initialization for the returned variable. It sounds odd that any of this would start to bite now after working fine for all those years, but I guess we could add some tests.

[kevinushey]

You are correct; IMHO the interface of find.package() is a bit weird in that it only returns paths for packages that are actually found.

That said, aren't you going to have even bigger problems if a package required for LinkingTo is not found or installed? Presumedly an error there implies the requisite package is not installed, or not on the library paths...

[sgsokol]

That said, aren't you going to have even bigger problems if a package required for LinkingTo is not found or installed? Presumedly an error there implies the requisite package is not installed, or not on the library paths...

As I said, in my case, an interactive session run OK through the tests, so all packages are well in place.
But generally speaking, a package name could be plainly misspelled.

[sgsokol]

I glanced at (my installed version of) find.package() from base R; out <- character() is the initialization for the returned variable. It sounds odd that any of this would start to bite now after working fine for all those years, but I guess we could add some tests.

It could start to bite suddenly not because of Rcpp but because, e.g. the variable package becomes currupted in some way and a clear error message could help to catch this situation.

[coatless]

Seems like this issue bites at the cppFunction()

Rcpp::cppFunction('void my_test() { Rcpp::Rcout << "testing"; }', 
                  depends = "fakepkg")
# Error in if (file.exists(pkgHeaderPath)) { :
# argument is of length zero

---

That said, sourceCpp() correctly handles the MIA package.

#include <Rcpp.h>
// [[Rcpp::depends(fakepkg)]]

// [[Rcpp::export]]
void my_test() { Rcpp::Rcout << "testing"; }

Rcpp::sourceCpp('~/Desktop/trash.cpp')
# Error: Package 'fakepkg' referenced from Rcpp::depends
# in source file trash.cpp is not available.

[eddelbuettel]

Fix in progress says

R> Rcpp::cppFunction('void my_test() { Rcpp::Rcout << "testing"; }', depends = "fakepkg")
Error: Package 'fakepkg' referenced from LinkingTo directive is not available.
R> 

Good enough?

Edit: Now in 83f6ef8

[sgsokol]

Just to tell the end of the story.
With this patch, it became clear that it was the package RcppArmadillo which was not found (while well indicated in DESCRIPTION/LinkingTo field and well present on the tested system). So I added an explicit call library(RcppArmadillo) in my RUnit.R and added RcppArmadillo also to DESCRIPTION/Suggests. It made to passe the tests without this mysterious bug popping up.