Closes #18, #28, #29

[mstackhouse]

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the codebase remains robust and consistent.

Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the devel branch until you have checked off each task.

• Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
• Updated relevant unit tests or have written new unit tests - See Unit Test Guide
• If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
• Update to all relevant roxygen headers and examples.
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Address any updates needed for vignettes and/or templates
• Update NEWS.md if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers)
• Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
• Address or fix all lintr warnings and errors - lintr::lint_package()
• Run R CMD check locally and address all errors and warnings - devtools::check()
• Link the issue so that it closes after successful merging.
• Address all merge conflicts and resolve appropriately.
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[mstackhouse]

@nicholas-masel this ended up a bit larger than I intended - but covered a couple different things! I added two new issues (linked) to cover the extra pieces.

[nicholas-masel]

@mstackhouse This looks good so far. I will continue to check this one, but I did add the following:

1. Warn user if the envsetup environment being used, does not match with a named autos environment. (We should add this to paths too).
2. Swapped in purrr for dplyr in our library calls for the autos tests. This is a package import, so we avoid a warning in check().
3. Swapped in do.call(set_autos) within library() so it is consistent w/the rprofile() call to set_autos(), making the input objects the same. I was surprised the objects differ with do.call() vs just calling set_autos() directly.

[mstackhouse]

@nicholas-masel

3. Swapped in do.call(set_autos) within library() so it is consistent w/the rprofile() call to set_autos(), making the input objects the same. I was surprised the objects differ with do.call() vs just calling set_autos() directly.

So - let me know what you think, but the reason I had to do this was because I didn't want to change the input parameter to set_autos(). The reason I'm do.call()ing it is because we list(...), which ended up giving this awkward nested structure. But - if we make set_autos() internal and just make the ... into like autos, which is then the equivalent of what list(...) should be then we avoid the do.call().

Since you suggested making set_autos() an internal function then I'm ok with simplifying the API. I didn't want to modify it before because the list structure it expects is pretty specific and made more sense as a named parameters as an exported function.

Does that sound better to you?

[nicholas-masel]

@nicholas-masel

3. Swapped in do.call(set_autos) within library() so it is consistent w/the rprofile() call to set_autos(), making the input objects the same. I was surprised the objects differ with do.call() vs just calling set_autos() directly.

So - let me know what you think, but the reason I had to do this was because I didn't want to change the input parameter to set_autos(). The reason I'm do.call()ing it is because we list(...), which ended up giving this awkward nested structure. But - if we make set_autos() internal and just make the ... into like autos, which is then the equivalent of what list(...) should be then we avoid the do.call().

Since you suggested making set_autos() an internal function then I'm ok with simplifying the API. I didn't want to modify it before because the list structure it expects is pretty specific and made more sense as a named parameters as an exported function.

Does that sound better to you?

@mstackhouse I'm good either way. If we change it, I would just want to confirm the structure passed set_autos() is the same as it was with do.call() so the checks work correctly.

[mstackhouse]

@nicholas-masel ready for re-review.

[mstackhouse]

@nicholas-masel we good to close? I filed an issue for the failing tests.

[nicholas-masel]

@nicholas-masel we good to close? I filed an issue for the failing tests.

yep, i'm good with it