Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closes #2143 Loosen restrict_derivation() assertion #2144

Closed
wants to merge 10 commits into from

Conversation

zdz2101
Copy link
Collaborator

@zdz2101 zdz2101 commented Sep 28, 2023

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 admiral 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, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - 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, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
  • 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 in the Development Section on the right hand side.
  • Address all merge conflicts and resolve appropriately
  • Pat yourself on the back for a job well done! Much love to your accomplishment!

@zdz2101 zdz2101 linked an issue Sep 28, 2023 that may be closed by this pull request
@github-actions
Copy link

github-actions bot commented Sep 28, 2023

Code Coverage

Package Line Rate Health
admiral 98%
Summary 98% (4386 / 4455)

Zelos Zhu added 3 commits October 6, 2023 17:57
Merge branch 'main' into 2143_restrict_derivation_lighten_assertion

# Conflicts:
#	DESCRIPTION
#	NEWS.md
@zdz2101 zdz2101 marked this pull request as ready for review October 6, 2023 18:00
Copy link
Collaborator

@bms63 bms63 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do any of the vignettes or documentation need to be changed for this update? I thought we said this wasn't allowed somewhere?

@zdz2101
Copy link
Collaborator Author

zdz2101 commented Oct 6, 2023

Do any of the vignettes or documentation need to be changed for this update? I thought we said this wasn't allowed somewhere?

Don't recall that portion, I imagine we should be okay, I would not say its particularly intuitive to call mutate using this either, had a hard time coming up with an appropriate test, I will say I did miss a roxygen blurb

@@ -12,7 +12,7 @@
#' The function must provide the `dataset` argument and all arguments
#' specified in the `params()` objects passed to the `arg` argument.
#'
#' Please note that it is not possible to specify `{dplyr}`
#' Please note that it is not advised to specify `{dplyr}`
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bms63 Was it this that you meant?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Umm...is this saying not to do dplyr::mutate() ?

Copy link
Collaborator Author

@zdz2101 zdz2101 Oct 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I'm not quite sure the origin story of this one, but all we wanted to do was loosen up the restriction such that we allow functions that don't necessarily have "dataset" as an argument. Sounds like there was a firm decision to outright not-allow dplyr functions or at least explicitly say they don't work since they don't file under the original restriction, but after lifting it, might lead to loosened/unintended-usage by users.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bundfussr any memory of this one?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I remember this sentence was added after the last clean-up to point out that dplyr functions can not be used. As this is changed now, we should remove the sentence completely.

NEWS.md Outdated
@@ -4,10 +4,13 @@

## Updates of Existing Functions

- `restrict_derivation()` now allows `dplyr` functions like `mutate` in the `derivation argument (#2143)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be `{dplyr}` instead of `dplyr`. Then it is autolinked.

Comment on lines -83 to -85
if (!is.null(args)) {
assert_function(derivation, names(args))
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should keep this call and update assert_function() such that it handles functions with ... argument. I.e., if the functions provides the ... argument, all arguments are accepted.

@zdz2101 , @bms63 , what do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if that is necessary. I feel like the original purpose of the assertion, was to check if all the appropriate necessary arguments were provided for that specific function. And the developer would likely know what is needed for that hard-check when using the assertion.

Many functions that use ... still have other necessary arguments anyway, so they can also just run assert_function(dev_fun) without checking params, to ensure it is a function. The remainder of that function, dev_fun in this case, should provide the appropriate errors/message handling if something is plugged in incorrectly.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the intention of the check was to ensure that all arguments specified for args are arguments of the function specified for derivation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I suppose it is a relatively short implementation, I can make an appropriate issue for it

@zdz2101
Copy link
Collaborator Author

zdz2101 commented Oct 10, 2023

Closing in favor of #2164

@zdz2101 zdz2101 closed this Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature Request: Lighten up restrictions of restrict_derivation()
3 participants