BiocPkgTools 1.4.6
Bioconductor has a rich ecosystem of metadata around packages, usage, and build status. This package is a simple collection of functions to access that metadata from R in a tidy data format. The goal is to expose metadata for data mining and value-added functionality such as package searching, text mining, and analytics on packages.
Functionality includes access to :
The Bioconductor build reports are available online as HTML pages.
However, they are not very computable.
The biocBuildReport function does some heroic parsing of the HTML
to produce a tidy data.frame for further processing in R.
library(BiocPkgTools)
head(biocBuildReport())## # A tibble: 6 x 9
## pkg version author commit last_changed_date node stage result
## <chr> <chr> <chr> <chr> <dttm> <chr> <chr> <chr>
## 1 a4 1.34.0 Tobia~ 2fe2~ 2019-10-29 13:08:20 malb~ inst~ OK
## 2 a4 1.34.0 Tobia~ 2fe2~ 2019-10-29 13:08:20 malb~ buil~ OK
## 3 a4 1.34.0 Tobia~ 2fe2~ 2019-10-29 13:08:20 malb~ chec~ OK
## 4 a4 1.34.0 Tobia~ 2fe2~ 2019-10-29 13:08:20 toka~ inst~ OK
## 5 a4 1.34.0 Tobia~ 2fe2~ 2019-10-29 13:08:20 toka~ buil~ OK
## 6 a4 1.34.0 Tobia~ 2fe2~ 2019-10-29 13:08:20 toka~ chec~ OK
## # ... with 1 more variable: bioc_version <chr>Because developers may be interested in a quick view of their own
packages, there is a simple function, problemPage, to produce an HTML report of
the build status of packages matching a given author regex. The default is
to report only “problem” build statuses (ERROR, WARNING).
problemPage()When run in an interactive environment, the problemPage function
will open a browser window for user interaction. Note that if you want
to include all your package results, not just the broken ones, simply
specify includeOK = TRUE.
Bioconductor supplies download stats for all packages. The biocDownloadStats
function grabs all available download stats for all packages in all
Experiment Data, Annotation Data, and Software packages. The results
are returned as a tidy data.frame for further analysis.
head(biocDownloadStats())## # A tibble: 6 x 7
## Package Year Month Nb_of_distinct_IPs Nb_of_downloads repo Date
## <chr> <int> <chr> <int> <int> <chr> <date>
## 1 ABarray 2020 Jan 56 117 Software 2020-01-01
## 2 ABarray 2020 Feb 52 126 Software 2020-02-01
## 3 ABarray 2020 Mar 28 52 Software 2020-03-01
## 4 ABarray 2020 Apr 0 0 Software 2020-04-01
## 5 ABarray 2020 May 0 0 Software 2020-05-01
## 6 ABarray 2020 Jun 0 0 Software 2020-06-01The download statistics reported are for all available versions of a package. There are no separate, publicly available statistics broken down by version.
The R DESCRIPTION file contains a plethora of information regarding package
authors, dependencies, versions, etc. In a repository such as Bioconductor, these
details are available in bulk for all inclucded packages. The biocPkgList returns
a data.frame with a row for each package. Tons of information are avaiable, as
evidenced by the column names of the results.
bpi = biocPkgList()
colnames(bpi)## [1] "Package" "Version"
## [3] "Depends" "Suggests"
## [5] "License" "MD5sum"
## [7] "NeedsCompilation" "Title"
## [9] "Description" "biocViews"
## [11] "Author" "Maintainer"
## [13] "git_url" "git_branch"
## [15] "git_last_commit" "git_last_commit_date"
## [17] "Date/Publication" "source.ver"
## [19] "win.binary.ver" "mac.binary.el-capitan.ver"
## [21] "vignettes" "vignetteTitles"
## [23] "hasREADME" "hasNEWS"
## [25] "hasINSTALL" "hasLICENSE"
## [27] "Rfiles" "dependencyCount"
## [29] "Enhances" "dependsOnMe"
## [31] "Imports" "importsMe"
## [33] "suggestsMe" "LinkingTo"
## [35] "Archs" "VignetteBuilder"
## [37] "URL" "SystemRequirements"
## [39] "BugReports" "Video"
## [41] "linksToMe" "OS_type"
## [43] "PackageStatus" "License_restricts_use"
## [45] "License_is_FOSS" "organism"Some of the variables are parsed to produce list columns.
head(bpi)## # A tibble: 6 x 46
## Package Version Depends Suggests License MD5sum NeedsCompilation Title
## <chr> <chr> <list> <list> <chr> <chr> <chr> <chr>
## 1 a4 1.34.0 <chr [~ <chr [4~ GPL-3 7210d~ no Auto~
## 2 a4Base 1.34.0 <chr [~ <chr [2~ GPL-3 11364~ no Auto~
## 3 a4Clas~ 1.34.0 <chr [~ <chr [1~ GPL-3 04152~ no Auto~
## 4 a4Core 1.34.0 <chr [~ <chr [1~ GPL-3 44d2e~ no Auto~
## 5 a4Prep~ 1.34.0 <chr [~ <chr [2~ GPL-3 d8f7b~ no Auto~
## 6 a4Repo~ 1.34.0 <chr [~ <chr [1~ GPL-3 14ea5~ no Auto~
## # ... with 38 more variables: Description <chr>, biocViews <list>,
## # Author <list>, Maintainer <list>, git_url <chr>, git_branch <chr>,
## # git_last_commit <chr>, git_last_commit_date <chr>,
## # `Date/Publication` <chr>, source.ver <chr>, win.binary.ver <chr>,
## # `mac.binary.el-capitan.ver` <chr>, vignettes <list>, vignetteTitles <list>,
## # hasREADME <chr>, hasNEWS <chr>, hasINSTALL <chr>, hasLICENSE <chr>,
## # Rfiles <list>, dependencyCount <chr>, Enhances <list>, dependsOnMe <list>,
## # Imports <list>, importsMe <list>, suggestsMe <list>, LinkingTo <list>,
## # Archs <list>, VignetteBuilder <chr>, URL <chr>, SystemRequirements <chr>,
## # BugReports <chr>, Video <chr>, linksToMe <list>, OS_type <chr>,
## # PackageStatus <chr>, License_restricts_use <chr>, License_is_FOSS <chr>,
## # organism <chr>As a simple example of how these columns can be used, extracting
the importsMe column to find the packages that import the
GEOquery package.
require(dplyr)
bpi = biocPkgList()
bpi %>%
filter(Package=="GEOquery") %>%
pull(importsMe) %>%
unlist()## [1] "bigmelon" "ChIPXpress" "coexnet" "crossmeta" "EGAD"
## [6] "GAPGOM" "MACPET" "minfi" "MoonlightR" "phantasus"
## [11] "recount" "SRAdb"For the end user of Bioconductor, an analysis often starts with finding a
package or set of packages that perform required tasks or are tailored
to a specific operation or data type. The biocExplore() function
implements an interactive bubble visualization with filtering based on
biocViews terms. Bubbles are sized based on download statistics. Tooltip
and detail-on-click capabilities are included. To start a local session:
biocExplore()The Bioconductor ecosystem is built around the concept of interoperability
and dependencies. These interdependencies are available as part of the
biocPkgList() output. The BiocPkgTools provides some convenience
functions to convert package dependencies to R graphs. A modular approach leads
to the following workflow.
data.frame of dependencies using buildPkgDependencyDataFrame.igraph object from the dependency data frame using buildPkgDependencyIgraphigraph functionality to perform arbitrary network operations.
Convenience functions, inducedSubgraphByPkgs and subgraphByDegree are available.A dependency graph for all of Bioconductor is a starting place.
library(BiocPkgTools)
dep_df = buildPkgDependencyDataFrame()
g = buildPkgDependencyIgraph(dep_df)
g## IGRAPH d625d85 DN-- 3256 28045 --
## + attr: name (v/c), edgetype (e/c)
## + edges from d625d85 (vertex names):
## [1] a4 ->a4Base a4 ->a4Preproc a4 ->a4Classif
## [4] a4 ->a4Core a4 ->a4Reporting a4Base ->methods
## [7] a4Base ->graphics a4Base ->grid a4Base ->Biobase
## [10] a4Base ->AnnotationDbi a4Base ->annaffy a4Base ->mpm
## [13] a4Base ->genefilter a4Base ->limma a4Base ->multtest
## [16] a4Base ->glmnet a4Base ->a4Preproc a4Base ->a4Core
## [19] a4Base ->gplots a4Classif->methods a4Classif->a4Core
## [22] a4Classif->a4Preproc a4Classif->MLInterfaces a4Classif->ROCR
## + ... omitted several edgeslibrary(igraph)
head(V(g))## + 6/3256 vertices, named, from d625d85:
## [1] a4 a4Base a4Classif a4Core a4Preproc a4Reportinghead(E(g))## + 6/28045 edges from d625d85 (vertex names):
## [1] a4 ->a4Base a4 ->a4Preproc a4 ->a4Classif
## [4] a4 ->a4Core a4 ->a4Reporting a4Base->methodsSee inducedSubgraphByPkgs and subgraphByDegree to produce
subgraphs based on a subset of packages.
See the igraph documentation for more detail on graph analytics, setting vertex and edge attributes, and advanced subsetting.
The visNetwork package is a nice interactive visualization tool that implements graph plotting in a browser. It can be integrated into shiny applications. Interactive graphs can also be included in Rmarkdown documents (see vignette)
igraph_network = buildPkgDependencyIgraph(buildPkgDependencyDataFrame())The full dependency graph is really not that informative to look at, though doing so is possible. A common use case is to visualize the graph of dependencies “centered” on a package of interest. In this case, I will focus on the GEOquery package.
igraph_geoquery_network = subgraphByDegree(igraph_network, "GEOquery")The subgraphByDegree() function returns all nodes and connections within
degree of the named package; the default degree is 1.
The visNework package can plot igraph objects directly, but more flexibility
is offered by first converting the graph to visNetwork form.
library(visNetwork)
data <- toVisNetworkData(igraph_geoquery_network)The next few code chunks highlight just a few examples of the visNetwork capabilities, starting with a basic plot.
visNetwork(nodes = data$nodes, edges = data$edges, height = "500px")For fun, we can watch the graph stabilize during drawing, best viewed interactively.
visNetwork(nodes = data$nodes, edges = data$edges, height = "500px") %>%
visPhysics(stabilization=FALSE)Add arrows and colors to better capture dependencies.
data$edges$color='lightblue'
data$edges[data$edges$edgetype=='Imports','color']= 'red'
data$edges[data$edges$edgetype=='Depends','color']= 'green'
visNetwork(nodes = data$nodes, edges = data$edges, height = "500px") %>%
visEdges(arrows='from') Add a legend.
ledges <- data.frame(color = c("green", "lightblue", "red"),
label = c("Depends", "Suggests", "Imports"), arrows =c("from", "from", "from"))
visNetwork(nodes = data$nodes, edges = data$edges, height = "500px") %>%
visEdges(arrows='from') %>%
visLegend(addEdges=ledges)[Work in progress]
The biocViews package is a small ontology of terms describing Bioconductor packages. This is a work-in-progress section, but here is a small example of plotting the biocViews graph.
library(biocViews)
data(biocViewsVocab)
biocViewsVocab## A graphNEL graph with directed edges
## Number of Nodes = 476
## Number of Edges = 475library(igraph)
g = igraph.from.graphNEL(biocViewsVocab)
library(visNetwork)
gv = toVisNetworkData(g)
visNetwork(gv$nodes, gv$edges, width="100%") %>%
visIgraphLayout(layout = "layout_as_tree", circular=TRUE) %>%
visNodes(size=20) %>%
visPhysics(stabilization=FALSE)The dependency burden of a package, namely the amount of functionality that
a given package is importing, is an important parameter to take into account
during package development. A package may break because one or more of its
dependencies have changed the part of the API our package is importing or
this part has even broken. For this reason, it may be useful for package
developers to quantify the dependency burden of a given package. To do that
we should first gather all dependency information using the function
buildPkgDependencyDataFrame() but setting the arguments to work with
packages in Bioconductor and CRAN and dependencies categorised as Depends
or Imports, which are the ones installed by default for a given package.
library(BiocPkgTools)
depdf <- buildPkgDependencyDataFrame(repo=c("BioCsoft", "CRAN"),
dependencies=c("Depends", "Imports"))
depdf## # A tibble: 97,884 x 3
## Package dependency edgetype
## <chr> <chr> <chr>
## 1 a4 a4Base Depends
## 2 a4 a4Preproc Depends
## 3 a4 a4Classif Depends
## 4 a4 a4Core Depends
## 5 a4 a4Reporting Depends
## 6 a4Base methods Depends
## 7 a4Base graphics Depends
## 8 a4Base grid Depends
## 9 a4Base Biobase Depends
## 10 a4Base AnnotationDbi Depends
## # ... with 97,874 more rowsFinally, we call the function pkgDepMetrics() to obtain different metrics
on the dependency burden of a package we want to analyze, in the case below,
the package BiocPkgTools itself:
pkgDepMetrics("BiocPkgTools", depdf)## ImportedAndUsed Exported Usage DepOverlap DepGainIfExcluded
## utils 1 245 0.41 0.01 0
## graph 1 116 0.86 0.10 0
## readr 1 109 0.92 0.30 3
## igraph 9 782 1.15 0.14 4
## RBGL 1 77 1.30 0.12 0
## htmltools 1 67 1.49 0.07 0
## xml2 1 66 1.52 0.04 0
## tidyr 1 62 1.61 0.38 2
## dplyr 7 261 2.68 0.32 0
## DT 1 37 2.70 0.25 4
## magrittr 1 35 2.86 0.01 0
## httr 3 91 3.30 0.13 0
## tibble 2 38 5.26 0.23 0
## jsonlite 1 17 5.88 0.01 0
## rvest 2 29 6.90 0.28 2
## htmlwidgets 1 13 7.69 0.13 0
## gh 1 10 10.00 0.26 2
## stringr 5 49 10.20 0.10 0
## BiocManager 1 5 20.00 0.03 0
## rex 4 17 23.53 0.04 1
## biocViews NA 31 NA 0.23 6
## tools NA 118 NA 0.01 0In this resulting table, rows correspond to dependencies and columns provide the following information:
ImportedAndUsed: number of functionality calls imported and used in
the package.Exported: number of functionality calls exported by the dependency.Usage: (ImportedAndUsedx 100) / Exported. This value provides an
estimate of what fraction of the functionality of the dependency is
actually used in the given package.DepOverlap: Similarity between the dependency graph structure of the
given package and the one of the dependency in the corresponding row,
estimated as the Jaccard index
between the two sets of vertices of the corresponding graphs. Its values
goes between 0 and 1, where 0 indicates that no dependency is shared, while
1 indicates that the given package and the corresponding dependency depend
on an identical subset of packages.DepGainIfExcluded: The ‘dependency gain’ (decrease in the total number
of dependencies) that would be obtained if this package was excluded
from the list of direct dependencies.The reported information is ordered by the Usage column to facilitate the
identification of dependencies for which the analyzed package is using a small
fraction of their functionality and therefore, it could be easier remove them.
To aid in that decision, the column DepOverlap reports the overlap of the
dependency graph of each dependency with the one of the analyzed package. Here
a value above, e.g., 0.5, could, albeit not necessarily, imply that removing
that dependency could substantially lighten the dependency burden of the analyzed
package.
An NA value in the ImportedAndUsed column indicates that the function
pkgDepMetrics() could not identify what functionality calls in the analyzed
package are made to the dependency. This may happen because pkgDepMetrics()
has failed to identify the corresponding calls, as it happens with imported
constants such as DNA_BASES from Biostrings, or that although the given
package is importing that dependency, none of its functionality is actually
being used. In such a case, this dependency could be safely removed without
any further change in the analyzed package.
We can find out what actually functionality calls are we importing as follows:
imp <- pkgDepImports("BiocPkgTools")
imp %>% filter(pkg == "DT")## # A tibble: 1 x 2
## pkg fun
## <chr> <chr>
## 1 DT datatablesessionInfo()## R version 3.6.3 (2020-02-29)
## Platform: x86_64-w64-mingw32/x64 (64-bit)
## Running under: Windows Server 2012 R2 x64 (build 9600)
##
## Matrix products: default
##
## locale:
## [1] LC_COLLATE=C
## [2] LC_CTYPE=English_United States.1252
## [3] LC_MONETARY=English_United States.1252
## [4] LC_NUMERIC=C
## [5] LC_TIME=English_United States.1252
##
## attached base packages:
## [1] stats graphics grDevices utils datasets methods base
##
## other attached packages:
## [1] biocViews_1.54.0 visNetwork_2.0.9 igraph_1.2.4.2 dplyr_0.8.5
## [5] BiocPkgTools_1.4.6 htmlwidgets_1.5.1 knitr_1.28 BiocStyle_2.14.4
##
## loaded via a namespace (and not attached):
## [1] tidyselect_1.0.0 xfun_0.12 purrr_0.3.3
## [4] vctrs_0.2.4 htmltools_0.4.0 stats4_3.6.3
## [7] yaml_2.2.1 utf8_1.1.4 RBGL_1.62.1
## [10] XML_3.99-0.3 rlang_0.4.5 pillar_1.4.3
## [13] glue_1.3.2 BiocGenerics_0.32.0 lifecycle_0.2.0
## [16] stringr_1.4.0 rvest_0.3.5 evaluate_0.14
## [19] Biobase_2.46.0 rex_1.1.2 RUnit_0.4.32
## [22] parallel_3.6.3 curl_4.3 fansi_0.4.1
## [25] Rcpp_1.0.3 readr_1.3.1 DT_0.12
## [28] BiocManager_1.30.10 graph_1.64.0 jsonlite_1.6.1
## [31] hms_0.5.3 digest_0.6.25 stringi_1.4.6
## [34] bookdown_0.18 gh_1.1.0 cli_2.0.2
## [37] tools_3.6.3 bitops_1.0-6 magrittr_1.5
## [40] RCurl_1.98-1.1 lazyeval_0.2.2 tibble_2.1.3
## [43] crayon_1.3.4 tidyr_1.0.2 pkgconfig_2.0.3
## [46] xml2_1.2.5 assertthat_0.2.1 rmarkdown_2.1
## [49] httr_1.4.1 R6_2.4.1 compiler_3.6.3