-
Notifications
You must be signed in to change notification settings - Fork 232
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
Default title and description for package docs #392
Conversation
@@ -113,4 +113,6 @@ obj_type.refMethodDef <- function(x) "rcmethod" | |||
#' @export | |||
obj_type.function <- function(x) "function" | |||
#' @export | |||
obj_type.package_doc <- function(x) "package_doc" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just call it "package" (it's implicitly about documentation)
- instantiated when documenting a value _PACKAGE
- found a slightly hackish way to pass the base path down to object_defaults
if (identical(name, "_PACKAGE")) { | ||
return(structure( | ||
list(pkg_name = packageName(env), | ||
base_path = getNamespaceInfo(ns, "path")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if there's a better way to find the base_path
here (or in object_defaults.package()
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In object_defaults
you might be able to do some manipulation of x$srcref$filename
, but I don't know if that contains the full path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In object_defaults()
, x doesn't have srcref -- only alias, value, and methods. Only the caller, add_defaults(), has access to srcref.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh true, but we could pass that on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course: dae13b2. I'm not sure if this is really better, though. Please let me know which you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do prefer it, just because it keeps the division of responsibilities more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated, but with modified division of responsibilities: 0a6f850
Works for me. More fields can be added later, such as author, version, ... |
docType = "package", | ||
title = as.character(desc$Title), | ||
description = as.character(desc$Description), | ||
aliases = c("NULL", paste0(pkg_name, "-package")), # See #202 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you make the comment a bit more direct? i.e. "NULL" prevents addition of default aliases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
- find_data() returns object that is sufficient to generate object defaults - in the case of a package, this is the DESCRIPTION - object_defaults() only converts the defaults to tags
Default title and description for package docs
Thanks! |
Maybe this is too close to the release to change, I think the underscore prefix for "_PACKAGE" is unnecessarily conservative. How often would someone previously be documenting a string of "PACKAGE". I could see someone documenting a Necessitating the leading underscore just complicates the typical case without a real benefit IMHO. |
I like the underscore because it makes it clear that this is a special string. We might add others in the future. |
Fair enough, consider me overruled 😄 |
Using
_PACKAGE
as sentinel value (to avoid unlikely collision with an object actually named "PACKAGE").No functionality yet, just to make sure we're on the same page here.Fixes #349.