Closed kenkellner closed 4 years ago
Looks like there's a conflict that needs to be resolved before this can be merged cleanly. Also, can you double check that it's okay to move Rcpp from Depends to Imports? I think Rcpp might need special treatment. For example, here's what Rcpp::Rcpp.package.skeleton
says:
The DESCRIPTION file gains an Imports line requesting that the package depends on Rcpp and a LinkingTo line so that the package finds Rcpp header files.
The NAMESPACE gains a useDynLib directive as well as an importFrom(Rcpp, evalCpp to ensure instantiation of Rcpp.
The DESCRIPTION file gains an Imports line requesting that the package depends on Rcpp and a LinkingTo line so that the package finds Rcpp header files.
I took that to mean that Rcpp shows up in the Imports line of DESCRIPTION (confusingly worded by also having depends in the sentence), along with LinkingTo (which is how I set it up in this PR).
This is what Dirk recommends: http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2014-January/006984.html
Also the way dplyr
does it:
https://cran.r-project.org/web/packages/dplyr/index.html
At any rate, all the tests and checks work with it set up this way.
And sorry, the two PRs both modified the same file so there was a merge issue. I'll clean it up.
Sounds good.
Moves
parallel
andRcpp
from depends to imports (so they no longer need to be explicitly loaded whenunmarked
is), and where possibleunmarked
now usesimportFrom
instead ofimports
. Ideallylattice
would also be moved out ofdepends
but doing so causes issues with some vignettes and examples that are expecting it to be loaded.These changes make
unmarked
a bit more in line with my understanding of NAMESPACE best practices, but they are not crucial. There are no changes as far as I know to user-facing behavior.