DESCRIPTION file must be properly formatted.
The following sections will review some important notes regarding fields of the
DESCRIPTION file and associated files.
All Bioconductor packages use an
x.y.z version scheme.
See Version Numbering for specifics to how the release
and devel Bioconductor versioning proceeds. When
first submitted to Bioconductor, a package should have pre-release version
The following rules apply:
xis usually 0 for packages that have not yet been released.
yis even for packages in release, and odd for packages in devel. Generally, do not bump this number especially in pre-release.
zis incremented whenever committing changes to a package.
The description should be a relatively short but detailed overview of what the package functionality entails. It should be at least three complete sentences.
The license field should preferably refer to a standard license (see wikipedia) using one of ’s standard specifications.
Be specific about any version that applies (e.g.,
Licenses restricting use, e.g., to academic or non-profit researchers, are not
suitable for Bioconductor. Core Bioconductor packages are typically
To specify a non-standard license, include a file named
LICENSE in your
package (containing the full terms of your license) and use the string
file LICENSE in this
The package should contain only code that can be redistributed according to the package license. Be aware of the licensing agreements for packages you are depending on in your package. Not all packages are open source even if they are publicly available.
For packages that include data, we recommend not including
However, this rarely proves to be a good thing.
In our experience it only slows down the loading of packages with large data.
All packages must be available via
the use of the
Remotes: field is not supported, hence dependencies only
available on other repositories (e.g. GitHub) are
Reuse, rather than re-implement or duplicate, well-tested functionality from other packages. Make use of appropriate existing packages (e.g., biomaRt, AnnotationDbi, Biostrings) and classes (e.g., SummarizedExperiment, GRanges, Rle, DNAStringSet), and avoid duplication of functionality available in other Bioconductor packages. See Common Bioconductor Methods and Classes. Bioconductor reviewers are very strict on this point! New packages should be interoperable with existing Bioconductor classes and should not reimplement functionality especially with regards to importing/reading data.
A package can be listed only once between
Enhances:. Determine placement of package based on the following
Imports:is for packages that provide functions, methods, or classes that are used inside your package name space. Most packages are listed here.
Depends:is for packages that provide essential functionality for users of your package, e.g., the
GenomicRangespackage is listed in the
GenomicAlignments. It is unusual for more than three packages to be listed as
Suggests:is for packages used in vignettes, examples, and in conditional code.Commonly, annotation and experiment packages (e.g.,
TxDb*) used in vignette and example code are included in this field thus avoiding a costly download. In the case where an external one-off function is required for package code, the package availability and usage can be done via:
if (!requireNamespace('suggPKG', quietly = TRUE)) stop("Install 'suggPKG' to use this function.") ::function()suggPKG
Enhances:is for packages such as
parallelthat enhance the performance of your package, but are not strictly needed for its functionality.
It is seldom necessary to specify or specific versions as dependencies, since the Bioconductor release strategy and standard installation instructions guarantee these constraints. Repositories mirrored outside Bioconductor should include branches for each Bioconductor release, and may find it useful to fully specify versions to enforce constraints otherwise guaranteed by Bioconductor installation practices.
This field is for listing any external software which is required, but not automatically installed by the normal package installation process.
If the installation process is non-trivial, a top-level
INSTALL file should
be included to document the process. If a user facing
README is included it
is also recommended to document the process there.
This field is required!
Specify at least two leaf node from
Multiple leaf terms are encouraged but terms must come from the same trunk or
package type (i.e.,
This field directs users to source code repositories, additional help
resources, etc; details are provided in the Writing R
This may be necessary to order class and method definitions appropriately during package installation.