菜单
Guides packaging DuckDB C extensions with R bindings, including repository layout, installed artifacts, SQL wrappers, generated docs, and native-versus-R responsibility boundaries. Use when building or restructuring an R package around a DuckDB extension.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Guides machine-readable function catalogs for DuckDB extensions, including a `functions.yaml` source-of-truth pattern that can drive docs, wrappers, aliases, examples, and consistency checks. Use when an extension exposes many SQL functions or multiple wrapper surfaces.
Guides development in the DuckHTS repo, including DuckDB extension work, Rduckhts package integration, vendored htslib workflows, SQL and tinytest coverage, wasm/webR constraints, and exact-compatible rewrites of upstream genomics tools. Use when working in github.com/RGenomicsETL/duckhts.
Guides creation, maintenance, checking, testing, documenting, and releasing R packages using project-native workflows such as Makefiles, tinytest, roxygen2, base R, and optional tools like usethis, pkgdown, air, or jarl. Use when working on any R package or CRAN-style package workflow.
Guides cache, index, and annotation-store design for bioinformatics rewrites, including when to use mainstream interoperable formats versus specialized high-performance encodings. Use when startup cost, repeated lookup performance, interval access, or annotation storage strategy are central design concerns.
Guides library-first bioinformatics rewrites that expose mature native code through bindings, extensions, FFI, or embedded runtimes across R, Python, SQL, and wasm. Use when building reusable interfaces around existing C/C++ libraries instead of standalone-only rewrites.
Guides responsible AI-assisted rewriting and porting of bioinformatics tools, combining rewrites.bio principles with practical validation, attribution, compatibility, and maintenance discipline. Use when planning or implementing a rewrite, reimplementation, or high-performance port of an existing bioinformatics tool.
| name | duckdb-c-extension-r-bindings |
| description | Guides packaging DuckDB C extensions with R bindings, including repository layout, installed artifacts, SQL wrappers, generated docs, and native-versus-R responsibility boundaries. Use when building or restructuring an R package around a DuckDB extension. |
Use this skill when the extension should be usable naturally from R without turning the R package into the native core.
A strong R integration usually keeps three things separate:
The R package should expose and document the extension well, but core semantics should remain native and SQL-centered.
A common practical layout is:
R/ for user-facing wrapper functionsman/ for generated docsinst/duckdb_extension/ for bundled extension sources or installable artifacts when packaging that wayinst/extdata/ for fixtures and examplesinst/function_catalog/ for machine-readable/generated SQL catalog filesinst/tinytest/ or tests/ for R-level testsNot every repo needs all of these, but the separation should stay clear.
R helpers should mainly do things like:
Do not let R become the only specification of semantics.
If the R package ships extension code or build artifacts:
For CRAN-oriented packages, bootstrap work should be small, explicit, and install-time oriented.
A strong pattern, seen in the general direction used around DuckTinyCC and DuckHTS-style R packaging, is:
inst/duckdb_extension/ when packaging that wayconfigure / configure.win only for narrow target-machine adaptationsrc/Makevars / src/Makevars.winThis is usually more CRAN-friendly than hiding large native bootstrap work inside first-call runtime behavior.
Typical acceptable bootstrap tasks include:
src/Makevars*Avoid bootstrap patterns where the first exported R call silently performs a large native build, downloads opaque binaries, or depends on undocumented shell state.
If R exports helpers such as pkg_feature() that call SQL functions:
Even if native tests pass, R can still fail via:
For projects with many SQL functions, a catalog-driven approach often helps generate:
README.Rmd with a custom knitr engine for executable docsA strong pattern used in both DuckTinyCC and DuckHTS is:
README.md generated from README.Rmdsql engine near the top of the documentThis keeps docs closer to the real extension workflow and makes drift much easier to catch.
DuckTinyCC uses a simple custom sql engine in README.Rmd that sends chunk contents to duckdb -unsigned and returns the output through knitr.
That is a good minimal pattern when you want runnable SQL docs without a lot of wrapper logic.
DuckHTS uses the same general approach but adds convenience logic to auto-load the built extension path before each SQL chunk.
That is a strong default when most examples should run against the just-built extension and you want short, readable SQL chunks in docs.
A minimal example looks like:
knitr::knit_engines$set(sql = function(options) {
code <- paste(options$code, collapse = "\n")
extension_path <- normalizePath("build/release/myext.duckdb_extension", mustWork = FALSE)
extension_path <- gsub("'", "''", extension_path, fixed = TRUE)
code <- paste(sprintf("LOAD '%s';", extension_path), code, sep = "\n")
if (isTRUE(options$eval)) {
out <- system2("duckdb", "-unsigned", input = code, stdout = TRUE, stderr = TRUE)
status <- attr(out, "status")
if (!is.null(status) && status != 0) {
stop(paste(out, collapse = "\n"))
}
knitr::engine_output(options, code, out)
} else {
knitr::engine_output(options, code, NULL)
}
})
Then the README can contain direct SQL chunks such as:
```{sql eval=TRUE, collapse=FALSE, comment=""}
SELECT * FROM my_table_function('example.dat');
```
If the project also generates a function catalog, prefer embedding that generated markdown in the README instead of copying the same list by hand.