Script to fix common reasons for "Lost braces" NOTE

[hturner]

#110 is an ongoing issue to submit PRs to CRAN packages with Rd issues. However, there are over 500 affected packages and it will take some time to work through them all manually.

We could look at two forms of automation here. This first sub-issue is to create a script to find and fix common problems leading to the "Lost braces" NOTE. These are documented in the comment from @bastistician #110 (comment) and the notes from the team that initially worked on #110: https://docs.google.com/document/d/1F9hoGi0_0WmxxpdHsxmPtn105L6yodLMafXnRfQgyY0/edit?usp=sharing.

This script could be used as a first pass to start a PR on a package that remains to be fixed.

[MichaelChirico]

FWIW, this week I deployed an LLM agent to fix this issue internally on 151 packages (many of which are just old versions behind their CRAN equivalents). The patches would require a second set of eyes because I was mainly focused on solving the R CMD check issue, not on improving documentation quality, but it could still be a useful start in some cases.

These are the packages I fixed where we have the same version as is on CRAN: {ada}, {ash}, {BBmisc}, {binom}, {ca}, {carData}, {cluster}, {combinat}, {drc}, {expss}, {factoextra}, {flashClust}, {irlba}, {lambda.r}, {mitools}, {mixmeta}, {nardl}, {NHANES}, {pglm}, {poLCA}, {profileModel}, {rappdirs}, {rattle}, {resample}, {reshape2}, {ROCR}, {rstatix}, {sqldf}, {SQUAREM}, {stargazer}, {tidyjson}, {TSA}, {viridisLite}. I crossed out a few that I already see patches for on the public GH repo, or for which the correct solution is probably just "re-run roxygenize()" rather than a manual patch to man/ files.

The full list of patches I tucked into details.

{actuar}, {ada}, {anMC}, {aod}, {ape}, {ATE}, {BayesTree}, {BBmisc}, {binom}, {brew}, {brglm}, {brms}, {bsynth}, {ca}, {carData}, {caret}, {CausalExpAnalysis}, {CDM}, {cgam}, {changepoint}, {clubSandwich}, {clusterGeneration}, {combinat}, {coneproj}, {Cubist}, {data.tree}, {deconvolveR}, {Deriv}, {distillery}, {drc}, {ellipse}, {elliptic}, {entropy}, {EnvStats}, {epitools}, {exactRankTests}, {expss}, {factoextra}, {fields}, {flashClust}, {flexclust}, {flexdashboard}, {flexmix}, {flexsurv}, {fuzzyjoin}, {GA}, {gamlss}, {gamlss.data}, {gamlss.dist}, {gdata}, {geepack}, {geex}, {GenomeInfoDb}, {GenomicRanges}, {getopt}, {ggdendro}, {ggpattern}, {glarma}, {gld}, {googleMisc}, {googlePlot}, {GPareto}, {grf}, {gtools}, {hdm}, {igraph}, {IRanges}, {irlba}, {kinship2}, {klaR}, {KrigInv}, {lambda.r}, {limma}, {Lmoments}, {LogicReg}, {longBet}, {lsa}, {mada}, {magic}, {mapproj}, {markovchain}, {matlab}, {maxLik}, {metafor}, {mice}, {miscTools}, {mitools}, {mixmeta}, {mixtools}, {mlbench}, {mnormt}, {multcomp}, {multcompView}, {multicool}, {nardl}, {NHANES}, {nleqslv}, {orientlib}, {PerformanceAnalytics}, {permute}, {pglm}, {plot3D}, {plotrix}, {poLCA}, {pracma}, {prismatic}, {profileModel}, {pscl}, {PSweight}, {psychTools}, {R2HTML}, {randtoolbox}, {rappdirs}, {raster}, {rattle}, {resample}, {reshape2}, {rethinking}, {Rglpk}, {RgoogleMaps}, {rms}, {ROCR}, {rstan}, {rstanarm}, {rstantools}, {rstatix}, {rstpm2}, {S4Vectors}, {scam}, {semTools}, {sm}, {splines2}, {sqldf}, {SQUAREM}, {stargazer}, {SuperLearner}, {survMisc}, {TeachingDemos}, {tensorA}, {tidyjson}, {tmle}, {TSA}, {twang}, {tweedie}, {urltools}, {usethis}, {vars}, {vcd}, {viridisLite}, {XBCF}, {XVector}

[villegar]

We have started a repo https://github.com/r-devel/auto_fix_cran_notes to work on the automation of this and #132

[eddelbuettel]

Out of curiousity, what can one do for packages without a repo? I am working with a current dual changeset for a package of mine ¹ where I manually crafted sixty PRs or patches over a good week, and maybe a third was emailed PRs. It would be so lovely if we could reply on repos, and I know @MichaelChirico sent PRs to encourage use of 'Url: ' in DESCRIPTIOON but it is a pita when one cannot. So I presume you just skip those?

Footnotes

1. RcppArmadillo. Upstream moved to 'C++14 or later' meaning a lot of packages enforcing C++11 (which was a good idea / a need a decade ago) are in trouble (CRAN is after them too) and compiler deprecation warning can no longer be suppressed (C++14 attribute instead of a macro with a possible override). ↩

[hturner]

@eddelbuettel, so far we are focusing on packages where there is a link to a repo, but for those that don't have such a link we could do the following:

• checkout the repo from the unofficial CRAN mirror, https://github.com/cran
• make the necessary changes
• create a patch with git diff > changes.diff
• email the patch to the maintainer, with instructions on how to apply the patch: patch -p1 < changes.diff (-p1 to strip leading directory components from file paths in the patch). Note patch is available via Git Bash or Cygwin / MSYS2 on Windows.

This won't work if their local copy has changed from the CRAN version, but they may be able to revert changes and apply the patch if they are using version control, or at least look at the diff and copy/paste if they're not using version control.

[eddelbuettel]

Thanks for confirming @hturner -- and yes I do the same. The possible 'delta' to their working version is a real issue but there is little we can do as I don't see having a public (git) repo imposed by CRAN as viable in the near to medium term.

[MichaelChirico]

We can also include a nudge to those e-mails along the lines of "NB: it is easier for us to contribute to packages shared in a public repo like Codeberg, GitLab, GitHub, ...", if authors are struggling with patches mismatched to their current sources hopefully it's motivation to put things more in open view. Could also point to some examples of PRs sent by the "easier" method.