Re: [Rd] Suggestion: help(<package name>)

From: Duncan Murdoch <>
Date: Wed 08 Jun 2005 - 11:05:21 GMT

Henrik Bengtsson wrote:
> It seems that it comes down to two things: 1) a standard Rd topic or
> alias <pkg>.package, and 2) enforcing this standard with R CMD check.
> Pro's and con's for (1):
> Pros:
> - Easy to find overview information on a package, that is, you know
> *where* to find it.
> - Allows a packages to link to another package.
> - Shows up in the HTML index page.
> - The <pkg>.package.html can be included on the CRAN package overview.
> This can then also become the author's "webpage" (kiosk?) for the
> package including installation instructions, license, future plans etc.
> Searchable on the web (==you can get information before trying to
> download/install, which sometimes fails; catch 22.)
> Cons:
> - Conflicts with other topic of the same name.
> - "Just another vignette" (?)
> Pro's and con's for (2):
> Pros:
> - Guarantees that a package can link to another package.
> - Standard immediately adopted.
> Cons:
> - Requires more maintainance.
> - Without automatic tools, redundancy is introduced (more maintainance).
> My comments:
> I think it is hard to argue that a standard similar to (1) is unwanted.
> Also, I don't think anyone has objected on this. The objection has been
> on (2). So my suggestion is that one writes up a standard on (1) and
> *ask* developers to follow it.
> If enforcement by R CMD check (2) was implemented too, then I think it
> only requires a single \alias{<pkg>.package} in any of the Rd files,
> because as far as I understand it at least one is required. This would
> not require much work ("almost cheap"). This would guarantee a link at
> least to something. A more advanced version is that the <pkg>.package.Rd
> file is automatically created by R CMD build if missing ("zero cost").

I really like this "zero cost" option. I think it addresses the main problem with the proposal (all the work for package writers that it creates), while keeping the main benefit (a standard place for package help *within the help system*).

It might be tricky to implement (the build tools aren't all in R and aren't consistent across platforms), but it seems like a reasonable compromise to me.

Duncan Murdoch

> To follow up on Gabor's suggestion to add more R CMD check granuality
> than errors and warnings. Using classes and the "new" exception
> handling, one could introduce a warning class called "Suggestion"
> (CranSuggestion), which gives suggestions to the user, but not enforce
> them (warning are not allowed on CRAN).
> To extend this idea further, one could add non-enforced checks if a
> package follows certain standardizations or not. I can image such
> checks to be plugins to R CMD check or standalone. Other solutions may
> also used. For instance, R CMD checkRCC could check a package against
> the coding convention RCC (
> Supplementary or complementary standards can provide their own checks.
> Such tools would be helpful for large projects to conform to the same
> standards, but not enforcing them. Packages following certain standards
> could then advertize this to help the user and other developers
> utilizing their packages and so.
> To summarize, I think it is good if you can communicate that you follow
> a certain standard, and it is even better if more peoples are using the
> same standard. I agree, that enforced standards are painful, if you
> disagree with them (or find the unnecessary).
> Cheers
> Henrik
> Robin Hankin wrote:

>>The reason I like .Rd files is that I can run the examples easily and, 
>>as Martin points out,
>>one does not need to learn a new syntax.
>>How about adding the following to R-exts:
>>"We encourage the package developer to include a file named 
>>foo.package.Rd in the "man"
>>directory, to provide a terse overview of the foo package.  This Rd file 
>>is intended to be
>>the first port of call for a new user of the package, and should provide 
>>(or point to)
>>working examples of the package's functionality.  It may also provide 
>>details or rationale
>>for the package's structure, if non-standard; and perhaps document other 
>>features of
>>the package that might escape a new user's notice.
>>See package foo for an example"
>>and package.skeleton() could be modified to  write a skeleton version of 
>>and put it in the man directory.
>>best wishes everyone
>>Duncan writes:
>>>My proposal (modified following the suggestions I've heard so far) is 
>>>as follows:
>>> - to check that a couple of help topic aliases exist (<pkg>.package 
>>>and <pkg>)
>>> - to recommend that <pkg>.package contain general information about 
>>>the package, and that <pkg> be an alias for it, if it isn't used for 
>>>some other purpose.
>>> - to write promptPackage() to help create an initial version of 
>>><pkg>.package.Rd.  It can get some information from the DESCRIPTION 
>>>file; perhaps it could go looking for a vignette, or the INDEX, or
>>> - to modify the other help system tools to make use of this (e.g. the 
>>>package:<pkg> heading on a page would become a link to the 
>>><pkg>.package alias, etc.)
>>>And as much as I do like (and read) the vignettes that are
>>>available, I also do agree that writing one other *.Rd file is
>>>easier for many new package authors than to write a
>>>vignette -- the package author already had to learn *.Rd syntax
>>>anyway -- and it's nice to be able to produce something where
>>>hyperlinks to the other existing reference material (ie. help
>>>pages) just works out of the box.
>>Duncan again:
>>>Currently R has 3 types of help:  the .Rd files in the man directory 
>>>(which are converted into plain text, HTML, compiled HTML, LaTex, DVI, 
>>>PDF, etc), the vignettes, and unstructured files in inst/doc.  We 
>>>currently require .Rd files for every function and data object.  
>>>Adding a requirement to also document the package that way is not all 
>>>that much of a burden, and will automatically give all those output 
>>>formats I listed above.  It will help to solve the often-complained 
>>>about problem   of packages that contain no overview at all.  
>>>(Requiring a vignette and giving a way to display it would also do 
>>>that, but I think requiring a .Rd file is less of a burden, and for 
>>>anyone who has gone to the trouble of creating a vignette, gives a 
>>>natural place for a link to it.  Vignettes aren't used as much as they 
>>>should be,  because they are hidden away where users don't see them.)
>>Robin Hankin
>>Uncertainty Analyst
>>National Oceanography Centre, Southampton
>>European Way, Southampton SO14 3ZH, UK
>> tel  023-8059-7743
>> mailing list

> ______________________________________________
> mailing list
> mailing list Received on Wed Jun 08 21:09:27 2005

This archive was generated by hypermail 2.1.8 : Mon 24 Oct 2005 - 22:27:08 GMT