repo: fix imports and remove unused standalone files #395
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
Please:
dajmcdon.
DESCRIPTION
andNEWS.md
.Always increment the patch version number (the third number), unless you are
making a release PR from dev to main, in which case increment the minor
version number (the second number).
(backwards-incompatible changes to the documented interface) are noted.
Collect the changes under the next release number (e.g. if you are on
0.7.2, then write your changes under the 0.8 heading).
epiprocess
version in theDESCRIPTION
file ifepiprocess
soonepipredict
andepiprocess
Change explanations for reviewer
epipredict-package.R
that were incorrect.import-standalone-types-check.R
andimport-standalone-obj-type.R
(introduced in 287 surface step name #383) and saw we don't use any of them in this repo, so I removed them. These standalone files are a development burden because (a) they present a manually-maintained dependency, (b) they don't declare their function dependencies, so I had to manually look through all the functions they use and manually write e.g.usethis::use_import_from("rlang", "is_list")
for every single one (until I gave up). I really don't think they're worth it at our stage of development because our packages aren't deeply core R packages that need to be absolutely as slim as possible.purrr
andlifecycle
are already transitive dependencies (see below). So I removed the lifecycle standalone (we only used that package once in this repo). I would remove thepurrr
standalone in this PR, but I can't because the behavior of the standalone functions has now diverged from purrr, so it's not a drop-in replacement (and the purrr documentation is now misleading for us as developers in this repo).Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch