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

Polish code and docs re: options for DESCRIPTION fields #367

Merged
merged 15 commits into from May 29, 2018
Merged

Conversation

jennybc
Copy link
Member

@jennybc jennybc commented May 26, 2018

Closes #233 create_package() should document options

Closes #159 Review all uses of getOption("devtools.SOMETHING")

Rationalize and document the use of options and internal defaults re: DESCRIPTION fields. Key principles:

  • Prefer usethis options to devtools options, but consult devtools options for backwards-compatibility
  • Eliminate redundant consultation of options
  • Adopt a modifyList() mentality vs. the "all or nothing" mentality of %||%
  • Add tests to make sure the order of precedence is what we say it is

@jennybc jennybc changed the title WIP re: options Polish code and docs re: options for DESCRIPTION fields May 28, 2018
@jennybc jennybc requested review from hadley and jimhester May 28, 2018 01:06
R/description.R Outdated
@@ -48,22 +58,15 @@ build_description <- function(name, fields = list()) {
}

build_description_list <- function(name, fields = list()) {
author <- getOption("devtools.desc.author") %||%
Copy link
Member

Choose a reason for hiding this comment

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

We're abandoning these individual options in favour of the omnibus usethis.description? If yes, need to call out in the NEWS (although it probably doesn't affect many people)

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, I failed to see that this wasn't just grabbing the "author" element of the "devtools.desc" list.

But it does seem like something we could probably drop. Or switch entirely to "devtools.desc.XYZ". Supporting usethis and devtools options, in individual and ombibus form seems unnecessary.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I'm fine with dropping it.

R/description.R Outdated
getOption("devtools.desc") %||%
list()
## the definitive source of user-supplied info: in this call or via options
fields <- utils::modifyList(
Copy link
Member

Choose a reason for hiding this comment

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

It might be worth doing some light type checking here - e.g. that it's a list with names?

Copy link
Member

Choose a reason for hiding this comment

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

And should all this logic be moved into build_description()? I think that would make the tests simpler since you wouldn't need so many temporary projects

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll try to move things around.

Part of the reason I tested via use_description(), though, was to test that directly specified fields override options & defaults, but in a targetted manner.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think it would be better to move all that code out so you can test independently of the writing.

@jennybc
Copy link
Member Author

jennybc commented May 29, 2018

I think this does everything we discussed @hadley:

  • Drop support of individual devtools' options and document this in NEWS.
  • Add check that user's fields is a dictionary-ish list.
  • Consolidate
    • data: option- and package-based defaults exposed via use_description_defaults()
    • logic: user's fields > usethis option > devtools option > usethis defaults, enacted in build_description_list()
  • Tests now focus on build_description_list()

R/description.R Outdated
#' }
use_description <- function(fields = NULL) {
name <- project_name()
check_package_name(name)
if (!is.null(fields)) check_is_named_list(fields)
Copy link
Member

Choose a reason for hiding this comment

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

If you moved this one line lower you could drop the conditional.

Copy link
Member Author

Choose a reason for hiding this comment

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

done

ByteCompile = "true"
build_description_list <- function(fields = list()) {
defaults <- use_description_defaults()
defaults <- utils::modifyList(
Copy link
Member

Choose a reason for hiding this comment

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

It feels to me like this belongs in use_description_defaults()

Copy link
Member Author

Choose a reason for hiding this comment

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

I actually made use_description_defaults() "data only" on purpose. It's the only easy way to see the usethis field defaults w/o reading source. Unless you care deeply, will leave this.

context("use_description")

test_that("build_description_list() defaults to values built into usethis", {
withr::with_options(
Copy link
Member

Choose a reason for hiding this comment

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

I think it's easier to read if you use local_options()

Copy link
Member Author

Choose a reason for hiding this comment

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

AHA! done.

fields = list(Title = "aaa", URL = "https://www.r-project.org")
)
## from user's fields
expect_identical(d$Title, "aaa")
Copy link
Member

Choose a reason for hiding this comment

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

Why test two fields from each case? Isn't one enough?

Copy link
Member Author

@jennybc jennybc May 29, 2018

Choose a reason for hiding this comment

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

One is an overwrite, one is novel. But I did remove one test case re: default values.

@jennybc jennybc merged commit 5fca4ce into master May 29, 2018
@jennybc jennybc deleted the options branch May 29, 2018 17:37
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.

None yet

2 participants