CRAN rejection for tidyverse dependencies not in mainstream repositories

We submitted a package this morning to CRAN, but it was rechecked because of pre-checks on the windows build. The Debian build was perfectly fine, but it looks like the windows build isn't seeing tidyverse packages in any mainstream repo.

One thing that's noteable is that the CRAN submission used R under development for the R version. This seems odd for a CRAN post. Is there a way to make sure that the latest stable version is used? Or is this possibly something temporary while the tidyverse packages are making their way back up? We tested using win-builder prior to submitting. We don't have any strong OS dependencies either, so at first glance this seems like it's not our issue.

The failed URL check also seems off - it worked fine with Debian, and the link is just to our our code coverage tag, which is indeed there.

CRAN feasibility check messages that flagged below.

* using log directory <blanking out>
* using R Under development (unstable) (2020-08-31 r79098)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file '<blanking out>/DESCRIPTION' ... OK
* this is package <blanking out>
* package encoding: UTF-8
* checking CRAN incoming feasibility ... WARNING
Maintainer: <blanking out>

New submission

Strong dependencies not in mainstream repositories:
  rlang, magrittr, dplyr, purrr, stringr, tidyr, tidyselect, tibble,
    lifecycle, forcats
Suggests or Enhances not in mainstream repositories:
  testthat, haven, knitr, rmarkdown, huxtable, tidyverse, readr,
    kableExtra, pharmaRTF

Found the following (possibly) invalid URLs:
  URL: https://codecov.io/gh/ <blanked out>
    From: README.md
    Status: Error
    Message: libcurl error code 35:
      	schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed).
  • CRAN incoming checks check your package on several R versions and OS. You might find R-hub useful for running such checks.
  • A wild guess of mine (and what you were hinting at) is that whatever checks the dependencies are in mainstream repositories was broken, because this lists all your dependencies? QC.R (so I'd try again with rhub::check_for_cran(), then CRAN)
  • You should not take a dependency on tidyverse itself, as explained in a blog post by @mara
  • Don't forget to also fix the URL issue. Some Rbuildignore their README, for others that don't, you could have a look at how they handle the codecov badge. (maybe the error was just a false positive though).

Forgot to add: good luck! :slight_smile:

2 Likes

It looks like this was just a timing issue - we resubmitted yesterday morning and it was fine. The R-hub checks are SUPER useful though, so thank you for that recommendation.

On the note of tidyverse - thank you for that article - it's a really good point. Fortunately we had listed out each of the individual dependencies and their version requirements - so tidyverse was just a reference to their inclusion in tidyverse, but that's a good blog post to have on hand and good to keep in mind.

I believe the URL issue was a bug because it didn't fail in debian, but ignoring the readme in the build is probably a wise thing to do regardless as then we just don't need to worry about readme content, so thank you for that recommendation as well!

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.