Glossary

Count of public functions declared by NAMESPACE export() directives, or R/ top-level definitions matching an exportPattern when only patterns are used.

n_exports in cran_code_summary

Number of top-level function definitions in R/ files that are not exported, i.e. helpers kept private to the package.

n_internal in cran_code_summary

Total lines across code files in R/, src/, tests/, man/, and vignettes/, with images and other binary files excluded. Rust sources under src/ count and vendored Rust crates do not.

loc_total in cran_code_summary

Raw line count of source files under the R/ directory, counting blank and comment lines too.

loc_r in cran_code_summary

Raw line count of compiled source and header files under src/, in C, C++, Fortran and Rust, with vendored Rust crates left out.

loc_src in cran_code_summary

Raw line count of every file under the tests/ directory, excluding binary and other non-code files.

loc_tests in cran_code_summary

Number of R function definitions the static analyzer detected across the package's R/ source, counted one per definition.

n_fns_r in cran_code_summary

Number of C++ functions the analyzer detected in the package's compiled sources under src/, one count per function.

n_fns_cpp in cran_code_summary

Number of C functions the analyzer detected in the package's compiled sources under src/, one count per function.

n_fns_c in cran_code_summary

Number of Fortran subroutines and functions the analyzer detected in the package's compiled sources under src/.

n_fns_fortran in cran_code_summary

Number of Rust functions the analyzer detected under src/, with vendored crates left out.

n_fns_rust in cran_code_summary

Share, from 0 to 1, of all counted lines of code (R, src, tests, docs, vignettes) living in compiled files under src/, Rust included and vendored Rust crates left out.

compiled_share in cran_code_summary

Total lines of source across all non-binary files in the package's man/ directory, i.e. its Rd help pages.

loc_docs in cran_code_summary

Share of the package's exported symbols that appear as a name or alias in at least one help page, with lowercase .rd files counted and Rd macro files under man/macros left out.

roxygen_doc_coverage in cran_code_summary

Share of help pages that include a references section. It counts references written in the help pages and says nothing about a bibliography file.

references_coverage in cran_code_summary

Share of help pages carrying an examples section, with lowercase .rd files counted and Rd macro files under man/macros left out.

examples_coverage in cran_code_summary

Number of help pages that contain at least one examples section, with lowercase .rd files counted and Rd macro files under man/macros left out.

help_pages_with_examples in cran_code_summary

Average share of a function's usage arguments lacking a matching entry in its arguments section, over exported functions, with lowercase .rd files counted.

undocumented_params_rate in cran_code_summary

Share of exported-function help pages that document their return value with a value section, with lowercase .rd files counted.

value_doc_rate in cran_code_summary

One when the analysed release carries a README at the package root, in Markdown, R Markdown, Quarto or plain text.

has_readme in cran_code_summary

One when the analysed release carries at least one vignette source under vignettes/, in any engine R builds.

has_vignettes in cran_code_summary

One when the analysed release carries a NEWS file in any location R reads, at the root or under inst/.

news_present in cran_code_summary

One when the analysed release carries an inst/CITATION file. The file is read as text and never run.

has_citation in cran_code_summary

Number of help pages in the analysed release, counting lowercase .rd files and leaving out Rd macro files under man/macros.

n_help_topics in cran_code_summary

Number of help pages whose examples run in a plain check, because some example code sits outside dontrun, donttest, dontshow and testonly.

rd_example_pages_run in cran_code_summary

Number of help pages whose examples run only when donttest examples are enabled, which R CMD check does with its as-cran option.

rd_example_pages_donttest_only in cran_code_summary

Number of help pages whose example code sits only inside dontrun, dontshow or testonly. Code in dontshow and testonly does run, but it is hidden from the reader, so no example the reader sees is run.

rd_example_pages_never_run in cran_code_summary

Approximate number of individual test blocks (such as test_that() calls) defined across the files in the package's tests/ directory.

n_test_cases in cran_code_summary

Number of tests the main test framework defines, counted in its own unit, such as test_that() blocks for testthat or test functions for RUnit.

n_test_units in cran_code_summary

Number of testthat blocks that skip themselves unless the NOT_CRAN variable is set. It is a lower bound, because only direct calls and one level of helper are followed.

n_test_blocks_cran_skipped in cran_code_summary

Total lines of code in the tests/ directory divided by the lines of code in R/, left blank when R/ has no lines.

test_to_code_ratio in cran_code_summary

Count of expect_snapshot() and expect_snapshot_file() calls in test R files, plus the number of stored snapshot files under tests/testthat/_snaps/.

snapshot_test_count in cran_code_summary

Flag set to one when any file at all exists under the package's tests/ directory, and zero otherwise.

has_tests in cran_code_summary

The Config/testthat/edition value declared in DESCRIPTION (typically 2 or 3), reported as an integer, and left blank when the field is absent.

testthat_edition in cran_code_summary

Share of NAMESPACE-exported functions whose name appears as a literal word token somewhere in the tests/ files, and left blank when nothing is exported.

exported_fn_test_linkage in cran_code_summary

Among test files that call RNG functions like sample/runif/rnorm/rbinom, the fraction that also call set.seed(), and left blank when none use randomness.

stochastic_seed_discipline in cran_code_summary

Whether the package includes any recognized continuous-integration config file such as a GitHub Actions workflow, Travis, AppVeyor, or CircleCI.

ci_present in bioc_code_summary

Largest number of distinct operating-system and R-version build combinations declared in any single GitHub Actions workflow matrix, or zero when there are none.

ci_matrix_breadth in bioc_code_summary

One when the Bioconductor git branch keeps a pkgdown config file. It describes the repository, not the release.

has_pkgdown in bioc_code_summary

Average cyclomatic complexity of the package's R functions, where each function scores one plus its number of branching decision points.

cyclocomp_mean in cran_code_summary

Highest cyclomatic complexity among the package's R functions, flagging its single most branch-heavy and hardest-to-test routine.

cyclocomp_max in cran_code_summary

Median cyclomatic complexity across the package's R functions, the typical function's branch count, resistant to a few very complex outliers.

cyclocomp_median in cran_code_summary

Average length in lines of a function's body across the package, a rough gauge of how large typical functions are.

loc_per_fn_mean in cran_code_summary

Number of R functions defined in the package, each treated as one node in its syntactic call graph.

net_n_nodes in cran_code_summary

Count of distinct directed caller-to-callee links where one package function calls another package function, excluding self-calls and duplicates.

net_n_edges in cran_code_summary

Highest number of call connections (functions it calls plus functions that call it) attached to any single function.

net_node_degree_max in cran_code_summary

Average call connections per function across all nodes, counting both calls made and calls received, including unconnected functions.

net_node_degree_mean in cran_code_summary

Count of package functions that neither call nor are called by any other package function (degree zero).

net_n_isolated in cran_code_summary

Number of connected components formed by functions linked through calls, where functions with no call edges are not counted.

net_n_clusters in cran_code_summary

Total number of .Call, .C, .Fortran, and .External invocations in R code that reach into compiled C/C++/Fortran routines.

n_native_call_sites in cran_code_summary

Number of S3 methods the package registers, counted from the S3method(generic, class) directives declared in its NAMESPACE file.

n_s3_methods in cran_code_summary

Count of formal S4 class definitions in the package's R source, identified by setClass() calls from the methods system.

n_s4_classes in cran_code_summary

Count of S4 generic functions the package declares in its R code, identified by setGeneric() calls.

n_s4_generics in cran_code_summary

Count of S4 methods the package defines for generics on specific classes, identified by setMethod() calls in R source.

n_s4_methods in cran_code_summary

Count of R6 class definitions in the package's R source, found by calls to the R6Class constructor from the R6 package.

n_r6_classes in cran_code_summary

Count of classes built with the newer S7 object system, identified by new_class() calls in the package's R source.

n_s7_classes in cran_code_summary

Count of Reference Classes (R5) defined in the package's R source, identified by setRefClass() calls from the methods system.

n_rc_classes in cran_code_summary

Number of packages the DESCRIPTION lists under Imports plus Depends, with version constraints stripped off and base R itself excluded.

n_deps_direct in cran_code_summary

Cross-version measure, derived from the ordered release series, of how much the direct dependency set shifts as packages are added or dropped between releases.

dependency_drift in cran_code_summary

A weighted tally of risky constructs in R/ code such as eval(parse()), system(paste()), non-literal Sys.setenv, and network calls inside load hooks.

unsafe_pattern_score in cran_code_summary

Number of likely credential leaks across non-binary text files such as AWS keys, GitHub tokens, and api-key/secret/password assignments to long literal strings.

secret_pattern_count in cran_code_summary

Per 1000 lines of R code, count of global-state writes such as <<-, assign() to the global environment, options() setters, and Sys.setenv().

global_state_write_density in cran_code_summary

Per 1000 lines of R code, how often dated idioms appear, such as bare T and F, risky 1-to-n index ranges, in-function require() or library() calls, and .Internal() calls.

deprecated_idiom_density in cran_code_summary

How often R/ code reaches into another package's private, unexported internals.

triple_colon_count in cran_code_summary

Number of distinct external OS-level dependencies listed in the DESCRIPTION SystemRequirements field, split on commas and "and" (case-insensitive).

system_requirements_count in cran_code_summary

1 when every token in the License field matches a known R-canonical or SPDX identifier from a fixed allowlist.

spdx_valid in cran_code_summary

1 when every license token is OSI-approved, excluding CC0, CC-BY, Unlimited, and bare file-reference licenses that cannot be verified.

osi_approved in cran_code_summary

When the license cites a LICENSE file, one if the file is present and, for MIT and BSD templates, its YEAR and COPYRIGHT HOLDER lines are filled. A full license text also counts as complete.

license_file_completeness in cran_code_summary

Exported symbols (functions, classes, methods) added to or removed from NAMESPACE between two versions.

Packages required under Imports, Depends, Suggests, LinkingTo, and Enhances, compared per type where the pipeline records them per version.

Bundled data objects, matched by name across versions. A change to the content fingerprint means the stored data itself changed.

Per-file lines added and removed between two versions, summed across the releases in between.

Which code-hosting site the package's source lives on, such as GitHub or GitLab, read from the repository id.

repo_id in vcs_signals_summary

Whether the source repository has been marked archived, meaning it is no longer actively developed.

is_archived in vcs_signals_summary

How many people have starred the repository, a rough popularity signal rather than a measure of quality.

stars in vcs_signals_summary

How many people have made their own copy of the repository to build on or contribute back.

forks in vcs_signals_summary

The number of bug reports or feature requests currently open and unresolved in the repository.

issues_open in vcs_signals_summary

The number of proposed code changes currently awaiting review or merging in the repository.

prs_open in vcs_signals_summary

How many tagged releases the maintainers have published over the life of the project.

releases_total in vcs_signals_summary

The total number of individual changes recorded in the project's development history, reflecting activity and age rather than quality.

commits_total in vcs_signals_summary

Distinct commit author identities in the repository history, counted by name and email, so one person committing from two addresses can count twice and anonymous commits count too.

contributors_total in vcs_signals_summary

The subject-area tags the maintainers attached to the repository to describe what it does.

topics in vcs_signals_summary

The usage license declared on the source repository, telling you how the code may be used.

license in vcs_signals_summary

The date of the most recent change to the code, a sign of how recently the project has been maintained.

last_commit_date in vcs_signals_summary

The change in the repository's star count over the past 30 days, showing whether interest is rising or falling.

trend_30d in vcs_signals_summary

Whether the repository shows a file for an AI coding tool, a pull request from its account, or a commit by it or crediting it. An ignore-file line, AGENTS.md or a shared .agents directory alone does not count, and absence never means no AI was used.

ai_markers_detected in vcs_signals_summary

The AI coding tool that was seen first in the repository.

ai_first_tool in vcs_signals_summary

The date the first AI coding tool was seen in the repository.

ai_first_date in vcs_signals_summary

Every AI coding tool found in the repository, one chip per tool.

ai_tools in vcs_signals_summary

The AI coding tool that appeared most recently in the repository. It is the newest to appear, not the most recently used.

ai_latest_tool in vcs_signals_summary

The date the newest AI coding tool first appeared in the repository.

ai_latest_date in vcs_signals_summary

One AI coding tool found in the repository, with its own row of findings.

tool in vcs_ai_signals

When that tool was first seen, as an exact date or as an 'on or before' date when the true start is uncertain.

first_seen_date in vcs_ai_signals

Which searches found the tool, from a file or ignore-file line to a pull request by its account, a pull request it wrote that a maintainer opened, a commit by its account, a commit message crediting it, or its name on a commit author.

evidence_tiers in vcs_ai_signals

Whether commits authored by the tool's own account were found.

authored in vcs_ai_signals

An AI tool that reviews pull requests or suggests edits, listed apart from tools that wrote the package.

tool in vcs_ai_review_signals

An AI coding tool used in a pull request from an outside contributor, never counted as the package's.

tool in vcs_ai_outside_prs

Whether GitHub shows a code of conduct for the repository, either a file the repository keeps or the default its owner keeps in a .github repository.

has_code_of_conduct in vcs_dev_tooling

Whether GitHub shows a contributing guide for the repository, either its own file or the default its owner keeps in a .github repository.

has_contributing in vcs_dev_tooling

Where the code of conduct comes from, the repository itself or its owner's default. The package page names the owner when the file is inherited.

coc_source in vcs_dev_tooling

Whether a GitHub Actions workflow in the repository runs R CMD check. It says the check is configured, not that it passes.

ci_rcmdcheck in vcs_dev_tooling

Whether a GitHub Actions workflow in the repository reports test coverage, for example through covr or Codecov.

ci_coverage in vcs_dev_tooling

Which operating systems the R CMD check workflow names, among Linux, macOS and Windows. Blank when the workflow names none, which is common for a matrix built from variables.

ci_platforms in vcs_dev_tooling

Whether the repository has a GitHub Pages environment or deployment. A deployment does not prove the site still answers.

has_pages in vcs_dev_tooling

The date of the newest GitHub Pages deployment, which is when the site was last deployed rather than when its content last changed.

pages_last_deploy in vcs_dev_tooling

The tool the repository builds its website with, pkgdown, altdoc, litedown or Quarto, read from the built site or from the configuration files the repository keeps.

site_generator in vcs_dev_tooling

When pkgdown last built the published site, read from the pkgdown.yml file the build leaves beside the site.

site_pkgdown_last_built in vcs_dev_tooling

Files a reader looks for, such as a README, NEWS, tests or vignettes, that the repository keeps and its .Rbuildignore leaves out of the release. Read only when the package sits at the repository root.

rbuildignore_excluded in vcs_dev_tooling

The Version field of the DESCRIPTION on the repository's default branch on the day of the scan, compared with the release on CRAN.

repo_desc_version in vcs_dev_tooling

The funding platforms GitHub shows for the repository, from its own FUNDING.yml or its owner's default.

funding_links in vcs_dev_tooling

Whether the repository is a fork of another repository on the same host.

is_fork in vcs_dev_tooling

Which continuous integration systems the Bioconductor git branch configures, drawn from GitHub Actions, Travis, AppVeyor and CircleCI. It comes from the Bioconductor git branch, not the weekly repository scan.

ci_type in bioc_code_summary

Whether any GitHub Actions workflow in the Bioconductor git branch runs on a pull request. It comes from the Bioconductor git branch, not the weekly repository scan.

ci_pr_gated in bioc_code_summary

How many times the package was downloaded from a given mirror over the past month.

download summaries

How many times the package was downloaded over the past three months.

download summaries

How many times the package was downloaded over the past twelve months, the headline download figure.

download summaries

Roughly how many downloads the package gets on an average day, derived from its yearly total.

download summaries

How many distinct computers downloaded a Bioconductor package in the most recent month.

download summaries

How many downloads a single mirror contributed for the package over the past month.

download summaries

What fraction of the package's tracked downloads comes from one particular mirror.

download summaries

Where the package sits on the most-downloaded list, where number 1 is the most downloaded, a popularity position rather than a quality score.

download summaries

Whether the package's downloads are rising or falling recently, shown as a signed percentage change.

download summaries

The total number of RPM files ever downloaded from the Fedora COPR CRAN build, counted per Fedora version.

download summaries

How many RPM files were downloaded from the Fedora COPR CRAN build over the past month.

download summaries

Every available channel's own headline total added into one figure. A package carried by several channels is counted once per channel, and the units are not the same, because most channels contribute a rolling 30 days while Bioconductor contributes one calendar month.

download summaries

One package's 30-day totals added across the channels that carry a 30-day column, after its rows are grouped case-insensitively on a single name. Bioconductor is not one of those channels, so it adds nothing here even though its column is drawn in the table.

download summaries

How many channels the combined figure was added from, meaning the channels marked available whose table is present in the database. Fedora COPR is collected and current and is not one of them, because it has no per-package table.

download summaries

Roughly how many downloads the package gets in an average month, the yearly total divided by twelve. It is arithmetic rather than a measured month, so it flattens release spikes and seasonal shape.

download summaries

How a channel's 30-day total compares with the period before it, as a signed percentage. The baseline is not a measured window. It is the 90-day total less the 30-day total, halved, which is the average of the two preceding 30-day windows, and it is left out for a channel with no 90-day column.

download summaries

How many rows in a channel's summary table carry a 30-day total above zero. It counts rows rather than packages the channel currently carries, so a package archived recently enough to keep a row is counted too.

download summaries

A channel's 30-day total divided by the number of rows with downloads. Downloads sit in a small number of packages, so this mean describes no actual package.

download summaries

The daily download total across every package on one channel, or across every channel that has a daily series when the All tab is showing. Bioconductor and Fedora COPR have no daily series, so neither is in it.

download summaries

The broken-down view of the ecosystem trend, where each channel's daily series is divided by its first non-zero day in the window and multiplied by 100. It compares the shape of the channels rather than their size, and a channel whose window holds only zeros is left out.

download summaries

The share of one channel's 30-day total held by its 100 largest packages, with a curve giving the same share at smaller and larger cut-offs. It is computed for a single channel and never for the combined figure.

download summaries

The packages with the largest rising and the largest falling stored trend on one channel, among those with at least 100 downloads in the window. The floor keeps small packages out, so a package can move a long way and still not be listed, and on CRAN archived packages are dropped as well.

download summaries

Dashed vertical lines on the download chart, one per distinct version, drawn in the package's colour at the version's published date and falling back to the date the version was first seen. Removals are left out, and only releases inside the plotted window are drawn.

download summaries

Dashed vertical lines on the download chart at R's own release dates, labelled with the R version. Major R draws the x.y.0 releases together with early R versions numbered in only two parts, and All R adds the patch releases.

download summaries

One chip per other channel that holds a positive figure for the package, naming the channel and its figure. The figures are not one window, since most are a year and autoCRAN's is 30 days, and a channel that carries the package but logged nothing in its window shows no chip at all, which reads the same as a channel that does not carry it.

download summaries

The earliest month the site holds data for a channel, written as "since" and a month. It is recorded per channel rather than read back from the stored rows, and a channel with none reads "not yet available".

download summaries

The latest data a pipeline published, as that pipeline reports it. It is not the end of the window a figure covers, and for Bioconductor and r2u it can sit a month ahead of the period their printed figures cover. The CRAN downloads pipeline publishes no value at all.

download summaries

One build target in the Fedora COPR project, a Fedora release paired with a processor architecture. COPR counts downloads against the chroot rather than against a package, which is why it has no per-package figure anywhere on the site.

download summaries

The share of the package's code lines that actually run when its automated tests are executed. Where the package carries compiled C, C++ or Fortran sources and those were traced too, their lines count toward this one number alongside the R lines.

line_pct in coverage_summary

The share of individual code expressions that run during testing, a finer-grained view than lines because one line can hold several. It is blended over compiled sources the same way line coverage is.

expr_pct in coverage_summary

The percentage produced by the tests pass. It is assigned from the same measurement as Line coverage and matches it on every stored row that carries both, so the two labels report one number under two names.

coverage_tests_pct in coverage_summary

How much of the package's code is exercised just by running the examples in its help pages.

coverage_examples_pct in coverage_summary

How much of the package's code is exercised by running its long-form tutorial documents.

coverage_vignettes_pct in coverage_summary

A short label saying whether the coverage measurement ran cleanly or hit an error, so a low or missing number can be read in context.

covr_status in coverage_summary

The test-coverage percentage for each individual source file, listed worst-covered first.

coverage_file_pct in coverage_summary

The test-coverage percentage of a single function, used to rank least-tested functions and tint the call graph.

function_coverage_pct in coverage_summary

The share of one source file's lines that run under the package's tests, listed worst-covered first. Files of compiled code are left out of this list even though the headline percentage counts them.

coverage_file.coverage_pct in coverage_summary

The share of one function's lines that run under the package's tests, used to rank the least-tested functions and to tint the call graph. A function that could not be matched to a coverage row keeps no value at all rather than a zero.

coverage_function.coverage_pct in coverage_summary

The measurement ran to the end and covr traced the package under its own test suite. It says the run finished, not that the package is well tested.

ok in coverage_summary

The published source tarball carries no R file anywhere under tests/, so there was nothing to run and no percentage is stored. It describes the tarball, not the maintainer's repository.

no_tests in coverage_summary

A test file raised an error while the suite ran. Rows with this status often still carry a percentage, so it is worth reading beside any number it sits next to.

test_error in coverage_summary

The package or one of its dependencies would not install, so nothing could be measured. The missing dependency is often one the CRAN and PPM index does not carry rather than a fault in the package.

build_fail in coverage_summary

The tests pass ran past the fixed per-pass time limit and was stopped, so no percentage is stored. It describes how long the suite takes to run under instrumentation, not how much of the package the suite reaches.

timeout in coverage_summary

covr itself raised an error before it could finish, so no percentage is stored. The fault is in the measurement rather than in the package's tests.

covr_error in coverage_summary

Which language a single function is written in, stored as r, c, cpp, fortran or rust. The call graph draws an R function as a circle and a compiled one as a square.

lang in coverage_summary

Whether a function is part of the package's public interface rather than an internal helper. It is recorded for R functions only, so a compiled function is never marked exported.

exported in coverage_summary

How many lines a single function's body spans. The call graph sizes each node by this figure, so a longer function draws as a larger shape.

loc in coverage_summary

How many independent paths run through one function, counted as one plus its branching decision points. It is recorded for R functions only, so the average and maximum shown for a package describe its R code even where the function count beside them includes compiled functions.

cyclocomp in coverage_summary

Which of the five stored graphs one call belongs to. An r edge is an R function calling another R function, a native edge is a resolved call from R into a compiled routine, and c (C and C++ together), rust and fortran cover calls between compiled functions. Only native changes how the line is drawn, so the plain grey line the legend calls an R call also carries every compiled-to-compiled edge.

graph in coverage_summary

The package built, installed, and passed all of CRAN's automated tests cleanly on that test machine.

CRAN check results

The package passed but CRAN flagged a minor, usually cosmetic issue worth a look that does not by itself remove the package.

CRAN check results

CRAN found a real problem that should be fixed and, if left unaddressed, can eventually get the package removed.

CRAN check results

The package failed to build, install, or run its tests on that test machine, meaning it is currently broken there.

CRAN check results

The check itself could not complete because the build or check process crashed outright, treated the same as a hard error.

CRAN check results

The package is no longer available on CRAN and only its past history is shown, rather than a live check result.

CRAN check results

How many of the test machines the package is checked on currently give a clean result, out of the total tested.

CRAN check results

The number of operating-system and R-version combinations the package was tested on.

CRAN check results

The specific test machines where the package is not fully clean, each labeled with its problem level and platform.

CRAN check results

The longest time it took to install and check the package on any single test machine, a sense of how heavy it is to build.

CRAN check results

A dated timeline of the package's past check outcomes, showing how its worst status changed over time.

CRAN check results

How many versions of the package the pipeline analyzed, written on the latest version's row only. It follows the tags or branches of the source the pipeline reads rather than a registry's release list, so read it as a lower bound.

n_versions in cran_code_summary / bioc_code_summary

The earliest release date among the analyzed versions, written on the latest version's row only. The dates come from the source the pipeline clones, not from a registry record.

first_release_date in cran_code_summary / bioc_code_summary

The most recent release date among the analyzed versions, written on the latest version's row only. On Bioconductor the dates track the release branch the pipeline read, so this can move without the package itself releasing.

latest_release_date in cran_code_summary / bioc_code_summary

The median number of days between one analyzed release and the next, written on the latest version's row only. The cell is labelled average but the figure is a median, and it is blank for a package with fewer than two analyzed versions.

release_cadence_days in cran_code_summary / bioc_code_summary

Among exported names a package dropped between releases, the share that carried no deprecation signal in the version before they went. Blank when a package never removed an export, so it is set on far fewer rows than the other history fields.

cold_removal_rate in cran_code_summary / bioc_code_summary

How the version number moved from the previous analyzed release, recorded as initial, major, minor, patch, or other when the step reads as none of those. The compare page takes it from the newer version's row, so the tag describes that version's own step rather than the span you selected.

bump_type in cran_code_summary / bioc_code_summary

The date recorded for one version, read from the tag or branch in the source the pipeline clones rather than from a registry record. On CRAN it is the mirror's tag date, which is why a small number of rows carry dates from before CRAN existed.

released in cran_code_summary / bioc_code_summary

The name in the DESCRIPTION Maintainer field for that version, with the email address split into a column of its own. The compare page shows the newer version's maintainer and falls back to the older one when the newer row carries none.

maintainer in cran_code_summary / bioc_code_summary

How many people the DESCRIPTION names for that version, counted from Authors@R where it is present and from the plain Author text otherwise. Every declared entry counts, including copyright holders and funders, not only the people who wrote code.

n_authors in cran_code_summary / bioc_code_summary

The people the DESCRIPTION names for a version, stored as given name, family name and roles. The compare page matches them by name across the two versions and draws a pill for each person added or dropped, so a name written differently in the two releases reads as one person leaving and another arriving.

authors in cran_code_summary / bioc_code_summary

The direct dependency names from Imports plus Depends for one version, with version constraints stripped and R itself left out. The compare page uses it for the sentence saying what the combined set gained or lost, which is what it falls back to when the per-type fields were never recorded for those two versions.

dep_list in cran_code_summary / bioc_code_summary

The advisory identifier, such as RSEC-2023-3, linking to its own page.

id in advisories

The released versions an advisory covers, worked out from its stated ranges against every version CRAN has published.

version in advisory_affected_versions

The first version the advisory names as free of the problem, or no fix when none has been released.

fixed in advisory_ranges

The CVSS rating published for the upstream flaw behind an advisory. It rates that library flaw, not how exposed the R package is.

rating in advisory_upstream

How many other packages list this one under Depends, Imports or LinkingTo, the fields they need to install, so they break if it goes. Each dependent counts once.

reverse-dependency graph

How many other packages list this one under Suggests and under none of the fields that make a dependent. They use it for tests, examples or optional features and run without it, so they are counted apart from the dependents.

reverse-dependency graph

How many more packages would be affected if this one broke, the ones that reach it only through a chain of dependents rather than directly.

reverse-dependency graph

How many packages installed alongside this one carry a share-alike license whose terms could carry over when you redistribute your work.

reverse-dependency graph

A breakdown of what kinds of licenses (permissive, weak-copyleft, copyleft) the packages in this one's install tree use.

reverse-dependency graph

How many R packages a person has a hand in, whether as author, maintainer, or contributor.

author summaries

How many packages a person is the official CRAN maintainer of.

author summaries

Total downloads of all of a person's packages over the last year, a reach signal rather than a quality one.

author summaries

How many other R packages rely on at least one of a person's packages to function.

author summaries

A single reach score where a value of h means the person has h packages each relied on by at least h other packages.

author summaries

The stretch of time from a person's first CRAN package to their most recent, showing how long they have been active.

author summaries

A fingerprint of the stored data itself so two datasets that share it hold identical values even when their names or packages differ.

the dataset catalog

A digest of a dataset's column names and their types, so two datasets that share it were described the same way column for column even when the rows differ. An object with no per-column schema has no names to fold in, and what stands in for them depends on the kind. A matrix is digested under one placeholder name per column, so what is left is its width and the type it holds. A raster is digested under a single entry for its cells, so what is left is the type it holds and nothing else, carried alike by rasters of quite different extents. An array, or a grid whose cells were never sliced into columns, is digested under the object's own name, a sparse matrix under its storage slots, and a list, a vector or a graph carries no schema digest at all.

the dataset catalog

How completely the file could be read when it was fingerprinted. Exact means every value was read. Degraded means part of it was not, and where the values were skipped for their size the fingerprint is taken over the bytes the reader went past instead of over the values.

the dataset catalog

How many datasets a package makes available to load with the data function, as opposed to internal objects bundled for its own use.

the dataset catalog

The number of columns in a rectangular dataset, left blank for data that is not a table.

the dataset catalog

Lines of code per file extension, summed over the five measured directories and drawn as the Code Composition bar. The page folds extensions into languages, so R/ and the R scripts under tests/ land in one R slice, and Rd help pages and vignette sources are languages of their own.

lang_breakdown in cran_code_summary / bioc_code_summary

Every file in the analyzed source tree, including images, data files and anything else no line count covers. It is the only figure here not limited to the five measured directories, so it is always larger than the file count behind the line totals.

n_files in cran_code_summary / bioc_code_summary

Whether the tree carries at least one file under src/ with one of the counted compiled extensions, which are c, cc, cpp, cxx, h, hpp, hxx, f, f90 and f95. A package whose compiled code is only Rust, Java or another unlisted language reads as No.

has_src in cran_code_summary / bioc_code_summary

Raw line count of every non-binary file under vignettes/, counting blank and comment lines. It is one of the five directories that add up to the total line count.

loc_vignettes in cran_code_summary / bioc_code_summary

The lowest R version the DESCRIPTION Depends field asks for, kept as the version string it declares. Blank when Depends names no R version at all.

min_r_version in cran_code_summary / bioc_code_summary

The C++ standard the package asks the compiler for, read from the first CXX_STD setting in src/Makevars or src/Makevars.win. Blank when no Makevars sets one, which includes packages that select a standard some other way.

cxx_standard_required in cran_code_summary / bioc_code_summary

Repository URLs the DESCRIPTION declares under Additional_repositories so its dependencies can be found outside the main registry. The row appears only when that list is not empty, and it names the hosts rather than the packages taken from them.

additional_repositories in cran_code_summary / bioc_code_summary

Total size on disk of every file under data/. It measures stored bytes, so a compressed data file counts as its compressed size, and it says nothing about how many objects those files hold.

data_size_total in cran_code_summary / bioc_code_summary

How many files sit under data/, shown beside the bundled data size. One file can hold several datasets, so this is a file count and not a dataset count.

num_data_files in cran_code_summary / bioc_code_summary

Third-party source carried inside the package, found either as a file with a known vendored name under src/ or inst/, or as a LICENSE or COPYING file inside a subdirectory of src/. The stored value holds both whether anything was found and the paths, and the cell currently reads 2 items when nothing was found, because it counts the two parts of that record instead of the file list.

bundled_third_party_code in cran_code_summary / bioc_code_summary

Words left in the first README the package carries once fenced code blocks and badge or image lines are removed. Blank when there is no README, and zero when the README holds nothing but code blocks and badges.

readme_prose_length in cran_code_summary / bioc_code_summary

Whether any vignette evaluates its code when the package is built, read from its chunk options. A vignette that turns evaluation off throughout, or keeps a precomputed .Rmd.orig source, counts as static. Rows from the 0.5.0 analyzer leave it blank when a source could not be read, and older rows read such a vignette as dynamic.

vignette_dynamic in cran_code_summary / bioc_code_summary

How much of a conventional changelog shape the NEWS file has, scored in thirds for per-version headings, bullet entries, and headings running from newest to oldest. Blank when there is no NEWS file, and the ordering third needs at least two headings before it can be met.

news_structure_quality in cran_code_summary / bioc_code_summary

The share of help pages carrying an examples block where the block is not one single dontrun or donttest wrapper, so some of the example code is meant to run. The stored column is the opposite share and the page shows its complement. Both are blank when no help page carries examples at all.

dontrun_example_ratio in cran_code_summary / bioc_code_summary

Whether the analysed release carries an inst/CITATION file, the file citation() reads first. It is read as text and never run, so the entry it builds is not shown here.

has_citation in cran_code_summary / bioc_code_summary

Whether the citation file cites a publication such as an article or a book, or only the software itself as a manual. Blank when there is no citation file or no entry type could be read.

citation_kind in cran_code_summary / bioc_code_summary

The journals the citation file points to by DOI, recorded as JSS, R Journal, JOSS or another venue. A DOI for the package itself or a Zenodo record is not counted as a venue.

citation_venue in cran_code_summary / bioc_code_summary

Whether the release carries inst/REFERENCES.bib or inst/REFERENCES.R, the bibliography that Rd citation macros read.

has_rd_bibliography in cran_code_summary / bioc_code_summary

The section of the NEWS file written for the analysed version, kept as the maintainer wrote it. Only the newest analysed version is kept, and a section longer than 16 KB is cut and marked as cut.

release_notes in cran_release_notes / bioc_release_notes

Which NEWS file R would read for the release, checked in the order inst/NEWS.Rd, NEWS.md, inst/NEWS.md, NEWS and inst/NEWS. Blank when the release carries none of them.

news_file in cran_code_summary / bioc_code_summary

How many help pages have examples that run in a plain check, out of the pages with an examples section. The rest split into pages that run only with donttest examples enabled, pages whose examples never run and pages whose examples hold no code.

rd_example_pages_run in cran_code_summary / bioc_code_summary

How many help pages the release carries, with the pages marked internal and any package overview page counted too. Lowercase .rd files count and Rd macro files under man/macros do not.

n_help_topics in cran_code_summary / bioc_code_summary

How many vignettes turn their code on or off from the environment, for example from the NOT_CRAN variable or from whether a suggested package is installed. Blank when the release has no vignettes.

vignette_eval_gated in cran_code_summary / bioc_code_summary

Among R/ function bodies that write to shared or global state, the share that also call on.exit to undo it. Blank when no function in the package mutates state, which is a clean result rather than a gap.

on_exit_coverage_rate in cran_code_summary / bioc_code_summary

The share of Imports and Depends entries that declare a minimum version, with the R entry itself left out. Only a greater-than-or-equal bound counts, so an exact or upper bound reads as no constraint, and the value is blank when a package declares no such dependencies.

dep_constraint_coverage in cran_code_summary / bioc_code_summary

The test framework with the most test files in the release, from testthat, tinytest, RUnit, testit, unitizer and plain R scripts. It reads none only when the release has no test files at all.

test_framework_primary in cran_code_summary / bioc_code_summary

How many tests the main framework defines, counted in its own unit. For testthat that is test_that() and it() blocks, for tinytest the expect calls, for RUnit the test functions and for plain scripts the script files.

n_test_units in cran_code_summary / bioc_code_summary

How many testthat blocks skip themselves unless the NOT_CRAN variable is set, through skip_on_cran(), skip_if_offline() or a helper that calls one of them. It is a lower bound, because deeper wrappers are not followed.

n_test_blocks_cran_skipped in cran_code_summary / bioc_code_summary

Every function definition found for the version shown, R and compiled counted together. Rows are not deduplicated by name, so two definitions sharing a name count twice, and the version-compare page's Functions (nodes) is a different figure because it counts R functions only.

functions_total in cran_functions / cran_call_edges

Whether a function is named by an explicit NAMESPACE export() directive. exportPattern, S3method, exportClasses and exportMethods do not set it, and a compiled function carries no value at all, which the detail rail still prints as internal.

exported in cran_functions / cran_call_edges

How many of the package's function rows were read from src/ by the C, C++, Fortran or Rust grammar rather than from R/. A row whose language was not recorded counts as R rather than as compiled.

compiled_functions in cran_functions / cran_call_edges

Every stored call between two functions of the same package for the version shown, with the R, native, C, Rust and Fortran graphs added together, which is why it runs above the version-compare page's Call edges for any package with compiled code. It counts stored rows rather than drawn lines, so an edge naming a target that has no function row of its own is in the total but not in the picture.

call_edges_total in cran_functions / cran_call_edges

Which of the five stored graphs one call belongs to. An r edge is an R function calling another R function, a native edge is a resolved call from R into a compiled routine, and c (C and C++ together), rust and fortran cover calls between compiled functions. Only native changes how the line is drawn, so the plain grey line the legend calls an R call also carries every compiled-to-compiled edge.

graph in cran_functions / cran_call_edges

The mean and the highest cyclomatic complexity across the function rows that carry one, which are the R rows only. The Code characteristics card on the same page shows a median and a maximum taken from the per-version summary instead, so the two cells answer different questions.

complexity_avg_max in cran_functions / cran_call_edges

How many physical lines one function's definition spans, from its opening line to its closing brace, blank and comment lines included. Every function row carries one, compiled functions included.

loc in cran_functions / cran_call_edges

How many branching decisions one function's body holds, scored as one plus its if, for, while and repeat statements and its && and || operators. Only R functions carry a value, so a compiled function reads as a dash wherever it is shown.

cyclocomp in cran_functions / cran_call_edges

Which grammar a function definition was read with, stored as r, c, cpp, rust or fortran and printed in capitals in the table, so a C++ function reads CPP there. That table ranks only rows carrying a coverage percentage and only R functions receive one, so every row it lists today reads R.

lang in cran_functions / cran_call_edges

The functions whose names appear in this one's body, and the functions whose bodies name it. Both lists are built from every stored edge for the package, including ones the view on screen does not draw, and a name repeats when the same call is stored more than once.

calls_called_by in cran_functions / cran_call_edges