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 licensed under
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.
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
Determine placement of package based on the following guidelines:
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 users a costly download. In the case where an external one-off function is required for package code, external package availability can be checked via
if (!requireNamespace('extraPKG')) stop(...).
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 biocViews.
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 Extensions manual,
This may be necessary to order class and method definitions appropriately during package installation.