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

Revise package metadata based on Wickham book #24

Open
31 tasks
xiangzhu opened this issue Oct 12, 2018 · 0 comments
Open
31 tasks

Revise package metadata based on Wickham book #24

xiangzhu opened this issue Oct 12, 2018 · 0 comments
Assignees

Comments

@xiangzhu
Copy link
Collaborator

xiangzhu commented Oct 12, 2018

Below is a check list of guidelines on the DESCRIPTION file from Wickham's package book: http://r-pkgs.had.co.nz/description.html

  • Every package must have a DESCRIPTION.
  • DESCRIPTION uses a simple file format called DCF, the Debian control format.
  • Each line consists of a field name and a value, separated by a colon.
  • When values span multiple lines, they need to be indented.
  • Both Imports and Suggests take a comma separated list of package names.
  • Putting one package on each line, and keeping them in alphabetical order. That makes it easy to skim.
  • Imports: packages listed here must be present for your package to work. In fact, any time your package is installed, those packages will, if not already present, be installed on your computer.
  • Explicitly refer to external functions using the syntax package::function().
  • If you use a lot of functions from other packages this is rather verbose. There’s also a minor performance penalty associated with :: (on the order of 5µs, so it will only matter if you call the function millions of times).
  • Suggests: your package can use these packages, but doesn’t require them. You might use suggested packages for example datasets, to run tests, build vignettes, or maybe there’s only one function that needs the package.
  • Packages listed in Suggests are not automatically installed along with your package. This means that you need to check if the package is available before using it (use requireNamespace(x, quietly = TRUE)).
  • The easiest way to add Imports and Suggests to your package is to use devtools::use_package().
  • If you need a specific version of a package, specify it in parentheses after the package name: MASS (>= 7.3.0).
  • Generally, it’s always better to specify the version and to be conservative about which version to require. Unless you know otherwise, always require a version greater than or equal to the version you’re currently using.
  • You should almost always use Imports, not Depends.
  • You can also use Depends to require a specific version of R, e.g. Depends: R (>= 3.0.1).
  • LinkingTo: packages listed here rely on C or C++ code in another package.
  • You can also list things that your package needs outside of R in the SystemRequirements field.
  • Title is a one line description of the package, and is often shown in package listing. It should be plain text (no markup), capitalised like a title, and NOT end in a period. Keep it short: listings will often truncate the title to 65 characters.
  • Description is more detailed than the title. You can use multiple sentences but you are limited to one paragraph. If your description spans multiple lines (and it should!), each line must be no more than 80 characters wide. Indent subsequent lines with 4 spaces.
  • Include a README.md file that goes into much more depth and shows a few examples.
  • To identify the package’s author, and whom to contact if something goes wrong, use the Authors@R field.
  • If your package includes code that you didn’t write, you need to make sure you’re in compliance with its license.
  • If you want to release your package to CRAN, you must pick a standard license.
  • Formally, an R package version is a sequence of at least two integers separated by either . or -. For example, 1.0 and 0.9.1-10 are valid versions.
  • R uses version numbers to determine whether package dependencies are satisfied.
  • A released version number consists of three numbers, <major>.<minor>.<patch>.
  • An in-development package has a fourth component: the development version. This should start at 9000. For example, the first version of the package should be 0.0.0.9000.
  • Increment the development version, e.g. from 9000 to 9001 if you’ve added an important feature that another development package needs to depend on.
  • Collate controls the order in which R files are sourced. This only matters if your code has side-effects; most commonly because you’re using S4.
  • LazyData makes it easier to access data in your package. Because it’s so important, it’s included in the minimal description created by devtools.
@xiangzhu xiangzhu self-assigned this Oct 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant