-
-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use pkg dir rather that getwd() for native routine registration #697
Conversation
…ckage rather than current working directory
getwd()
for native routine registration
As it turns out this does fix the devtools problem after all. To further clarify, there will be a potential problem if you invoke compileAttributes on a package within the working directory of another package that includes native routines. So with the devtools test, it was probably invoking something like this with devtools as the working directory: devtools::install("/tmp/test-pkg-dir") Wherein So as a practical matter, this will affect out-of package source directory use of devtools package building functions. Note that this is all at development time and any error will be immediately manifest and correctable by installing the development version of Rcpp (just reinforcing that I think no patch release to CRAN is required). |
Codecov Report
@@ Coverage Diff @@
## master #697 +/- ##
==========================================
+ Coverage 89.51% 89.54% +0.03%
==========================================
Files 66 66
Lines 3586 3587 +1
==========================================
+ Hits 3210 3212 +2
+ Misses 376 375 -1
Continue to review full report at Codecov.
|
CRAN wants us to fix the failing devtools test caused by the change in behavior. So either there needs to be a devtools release that works around this or an Rcpp release with the fix from this PR. We would prefer the latter, |
Feel free to point them to the pull request and tell them to help themselves. In other words I don't mind them camouflaging 0.12.11.1 as 0.12.11 but I do not plan to make a point release. I would go as far as putting 0.12.11.1 onto the rcpp-drat repo. They can install from there... Or just make a devtools point release. |
Rcpp releases are huge affairs (16 hours of revdep checking, CRAN rebuilding a huge number of binaries, etc.). The devtools workaround would just be to setwd to the pkg dir before calling compileAttributes, something like this: withr_with_dir(pkg$path, {
Rcpp::compileAttributes()
}) |
Is there a reason this R CMD check failure wasn't reported to us during the initial round of release checks? |
Because devtools lists Rcpp as only a Suggests dependency rather than
Imports (and we only check Depends, Imports, LinkingTo)
…On Tue, May 23, 2017 at 4:16 PM, Hadley Wickham ***@***.***> wrote:
Is there a reason this R CMD check failure wasn't reported to us during
the initial round of release checks?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#697 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGXxw1Xl8rJQz9V_Rxbc1u-jqCP1bSfks5r8z6OgaJpZM4NjzLd>
.
|
Is there a reason the devtools team didn't test the release candidate? |
Because we were never notified of it? But this thread clearly isn't going anywhere, so I don't see any point in continuing the conversation. We'll rush a devtools fix for CRAN. |
If you depend on a tool, maybe you should follow it? This is all spillover from the R 3.4.0 release and their somewhat poorly communicated decisions / changes and their impact on us. We made the package registration code change late, and it was risqu'e to release. So you got burned. Such is life. I don't use devtools. I believe a few folks within Rcpp Core do. Still nobody noticed. Not ideal. And again: "Suggests != Depends". My life is too short too, so I cannot test Suggests: or recursive Depends:. One day when the R Consortium builds a more powerful test battery we may get to issues like this. Right now we don't. |
Execute tools::package_native_routine_registration_skeleton within package rather than current working directory.
Typically
compileAttributes
is called with the package directory as the current working directory. However, it can be invoked via e.g.compileAttributes(pkgdir = "foo")
. In that case we were callingtools::package_native_routine_registration_skeleton
in the current working directory rather than in the specifiedpkgdir
. This would result in missing registrations (or over-registrations if the current directory happened to be another package).The bug should not affect most normal uses of
compileAttributes
so there isn't a need to do a patch release for this fix.