RCPP_VERSION is still set to 1.0.2

[xrobin]

Since the 1.0.3 release I have seen an inconsistency with RCPP_VERSION which is still set to 65538, ie 1.0.2.

Is there a reason inst/include/Rcpp/config.h still has:

#define RCPP_VERSION            Rcpp_Version(1,0,2)

[eddelbuettel]

Yup, my bad. I edited the string versions in the config.h but only now set the numeric vector used for the comparison.

So for this release, use packageVersion("Rcpp"), or compare the string as well which shipped as "1.0.3". I'll try again to do the Right Thing (TM) on the next releases. There wasn't anything breaking, really, this time so not too much harm done.

But thanks for the heads-up.

[eddelbuettel]

BTW as you referencing from pROC, it is one of those package that fails each and every time I run reverse depends. Maybe we should coordinate why. (There are a few more, and I have not had time to chase this. See here for summaries.

[xrobin]

Thanks! I'll consider going with the string for the next update.

I'd be happy to help with the reverse depends. I dread them myself so I'd love to make it easier for you. I can't see why it would fail though, and I'm not sure how to get started. The QuickSummaries are very terse and indeed show that pROC is failing, but I can't find any additional info about why. Any pointers would be helpful here.

[eddelbuettel]

• Sounds good re the string; and I will try my best to once again update the numerics next time too

• Yes, I am aware of the terseness; those are summaries. Details are on the box I get to run these (Debian testing) but I should also note that at times the issues had occassional "localness" to the box.

Right now, I am seeing

* checking tests ... [93s/131s] ERROR
  Running ‘testthat.R’ [93s/131s]
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  ══ testthat results  ═══════════════════════════════════════════════════════════
  [ OK: 8516 | SKIPPED: 10 | WARNINGS: 62 | FAILED: 11 ]
  1. Error: Ggroc screenshot looks normal (@test-ggroc.R#9)
  2. Error: Ggroc list screenshot looks normal (@test-ggroc.R#16)
  3. Error: Ggroc list can take multiple aes (@test-ggroc.R#23)
  4. Error: Ggroc list extra aestetics screenshot looks normal (@test-ggroc.R#30)
  5. Error: Ggroc list with group facet screenshot looks normal (@test-ggroc.R#39)
  6. Error: plot draws correctly (@test-plot.R#13)
  7. Error: legacy.axis works correctly (@test-plot.R#25)
  8. Error: Advanced screenshot 1 works correctly (@test-plot.R#47)
  9. Error: Advanced screenshot 3 works correctly (@test-plot.R#89)
  1. ...

  Error: testthat unit tests failed
  Execution halted
* DONE
Status: 1 ERROR, 1 NOTE

but as you have a clean bill of health here at CRAN checks the error may be something different.

[xrobin]

Oh these are vdiffr graphical tests!

They are skipped on CRAN, but I run them with Travis CI and AppVeyor. I know they run there because they broke with the ggplot2 3.2 update. Now as far as I can remember that came after the last release of pROC, so the CRAN version will fail with current ggplot2.

Long story short, you can ignore those errors (maybe you want to set VDIFFR_RUN_TESTS=false as suggested by vdiffr: it's a monitoring tool rather than something that should cause failures), and it's time for me to push an update to CRAN. (I've been postponing it as there are significant API changes breaking other packages but I've given them prior notice and enough time now so I'll aim to do it in the next few weeks).

[eddelbuettel]

It is a little hard for me to keep track of env vars for 1800+ projects. Any chance you could not run them ? Any other common env var we could agree on?

(Rcpp does this differently. "Dev" package numbers like 1.0.3.1 with four parts get all tests, "Release" package numbers like 1.0.3 do not. CRAN only see the latter. It's easier because it is endogeneous.)

[xrobin]

I guess with VDIFFR_RUN_TESTS=false is one of the most generic way to go. At least it's the "official" vdiffr way to go. This variable is checked by the vdiffr package directly so any failure of vdiffr tests in other pakages will disappear too. I don't think you should be running any of them anyway.

If you prefer I can also skip them based on a variable of your choice. I'm not sure if there would be a generally accepted choice here?

[eddelbuettel]

Many packages look for CI (set on Travis) or some CRAN / NOT_CRAN or whatever.

[xrobin]

I reckon that's what vdiffr does too, they say they check for CI and NOT_CRAN and run if any of these is set.

[eddelbuettel]

I'll see about setting env vars. Might as well I suppose ...

[eddelbuettel]

Done in eddelbuettel/prrd@0a4de0a -- thanks for the hint.

[xrobin]

Awesome, glad I could help.