The package is archived on CRAN because of errors I cannot reproduce.

[wlandau]

Prework

• Read and agree to the code of conduct and contributing guidelines.
• Confirm that your issue is most likely a genuine bug in the targets package itself and not a user error, known limitation, or bug in another package that targets depends on. For example, if you get errors running tar_make_clustermq(), try isolating the problem in a reproducible example that runs clustermq and not targets. And for miscellaneous troubleshooting, please post to discussions instead of issues.
• If there is already a relevant issue, whether open or closed, comment on the existing thread instead of posting a new issue.
• Post a minimal reproducible example like this one so the maintainer can troubleshoot the problems you identify. A reproducible example is:
  • Runnable: post enough R code and data so any onlooker can create the error on their own computer.
  • Minimal: reduce runtime wherever possible and remove complicated details that are irrelevant to the issue at hand.
  • Readable: format your code according to the tidyverse style guide.

Description

I just submitted targets version 0.4.1 to CRAN last week. Today, I got an email from Brian Ripley:

Version 0.4-1 is still failing on macOS so it and tarchetypes have been
archived.

A recheck on my own Intel Mac today gives the same check ERRORs as
reported on the CRAN results page.

Do not submit again without reproducing this error and confirming it has
been corrected.

The CRAN check errors (all unique to targets version 0.4.1) are at https://cran-archive.r-project.org/web/checks/2021/2021-04-25_check_results_targets.html.

I have been unable to reproduce them. I tried a fresh installation of R 4.0.2 and packages on my own Intel Mac, as well as GitHub Actions and both Mac builds at https://builder.r-hub.io/. All those checks pass.

The error is somehow related to a very simple internal R6 class: https://github.com/ropensci/targets/blob/4deba948b8d6ecf82511a5a58b1eb9a0addcf2bd/R/class_config.R. The elusive failing tests are ostensibly in https://github.com/ropensci/targets/blob/4deba948b8d6ecf82511a5a58b1eb9a0addcf2bd/tests/testthat/test-class_config.R, but they always pass for me.

If anyone has a system that can reproduce these errors, please let me know. The source of targets 0.4.1` is available at https://cran.r-project.org/src/contrib/Archive/targets/targets_0.4.1.tar.gz, and the analogous GitHub release is at https://github.com/ropensci/targets/releases/tag/0.4.1.

[petrbouchal]

Tried on R 4.04. on an Intel Mac and all tests pass...

[wlandau]

Thanks for trying, I appreciate it.

On reflection, I think the problem was the use of file modification time stamps to monitor the status of _targets.yaml. I originally did this for performance reasons, but there is a way around it. Time stamps are unpredictable from machine to machine, but everything else in https://github.com/ropensci/targets/blob/main/R/class_config.R is super simple R code. Would be nice to confirm the issue is fixed, but it may not be possible until the actual CRAN resubmission.

[ianmcook]

I tried it on an Intel Mac with R 4.0.5 and couldn't reproduce it.

It's like the file connection is being opened in non-blocking mode—but it's not, so the timestamp checks seem like the likeliest explanation.

[wlandau]

Thanks @ianmcook for trying.

I think the issue is fixed, and I resubmitted targets to CRAN. Hopefully it will be back up in the next week or 2.