DESCRIPTION file must be properly formatted.
The following sections will review some important notes regarding fields of the
DESCRIPTION file and associated files.
This is the name of the package. The repository name and the name of the Package in the description should match (including case-sensitive).
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.
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
In our experience it only slows down the loading of packages with large
data. There are of course exceptions; please provide reasoning if included.
All packages must be available via Bioconductor’s biocViews or
CRAN; the use of the
Remotes: field is not supported, hence dependencies only
available on other repositories (e.g. GitHub) are
not allowed nor is specifiy an explicit version of a package.
Reuse, rather than re-implement or duplicate, well-tested functionality from other packages. Make use of appropriate existing packages (e.g., biomaRt, AnnotationDbi, Biostrings, etc.) and classes (e.g., SummarizedExperiment, GenomicRanges::GRanges, S4Vectors::Rle, Biostrings::DNAStringSet, etc.), 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:
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; do not try to install a
dependency for a user anywhere in the package (i.e. readme, r code, man pages,
vignette). You may show instructions only in unevaluated sections.
This field is required!
Specify at least two leaf node from biocViews.
Multiple leaf terms are encouraged but terms must come from the same trunk or
package type (i.e.,
biocViews terms are case-sensitive.
The field name “biocViews” is case-sensitive and must begin with a lower-case ‘b’. Please use a single line with biocViews seperated by commas
biocViews: GeneTarget, SingleCell).
This field directs users to source code repositories, additional help
resources, etc; details are provided in the Writing R Extensions
This may be necessary to order class and method definitions appropriately during package installation.