数据分析【免费下载链接】dplyrdplyr: A grammar of data manipulation项目地址https://gitcode.com/gh_mirrors/dp/dplyr点击查看免费下载revdep/failures.md是 dplyr 仓库在开发版本1.2.1.9000见 DESCRIPTION发布前执行逆向依赖reverse dependency检查后生成的失败清单对 5393 个下游包5389 个来自 CRAN、4 个来自 Bioconductor分别用「CRAN 版 dplyr」与「开发版 dplyr」运行R CMD check最终有 28 个包未能完成检查详见 revdep/cran.md。本文以该报告为主体逐一讲解其条目结构、状态分类与各类失败根因并结合仓库中的 NEWS.md、R/源码与 revdep/README.md 交叉验证帮助下游包维护者快速定位「哪些失败真的由 dplyr 变更引起、哪些只是第三方环境问题」并给出具体的迁移与排查方法。一、报告定位dplyr 生态兼容性检查的第一道哨兵1.1 revdep 目录里四份文件的分工仓库根目录下revdep/目录集中存放逆向依赖检查的全部产出文件作用revdep/README.md汇总总览Failed to check (28)与New problems (172)两张索引表revdep/cran.md面向 CRAN 的摘要5393 个逆向依赖的检查规模、172 个新问题、24 个未能检查的包及其首行错误revdep/failures.md本文主体每个失败包的完整检查日志Devel / CRAN 双版本对照revdep/problems.md172 个「新问题」tests 报错、examples 报错、NOTE/WARNING 等的详细清单四份文件的关系可以概括为README.md是指针目录cran.md是给 CRAN 维护者看的摘要failures.md记录「连安装都失败」的最严重一级problems.md记录「能安装但检查出问题」的次一级。本文聚焦最严重的failures.md。1.2 检查机制同一包跑两遍对比得出「新失败」从 revdep/cran.md 可确认检查方式We checked 5393 reverse dependencies (5389 from CRAN 4 from Bioconductor), comparing R CMD check results across CRAN and dev versions of this package.即每个下游包都会在两种 dplyr 环境下各跑一次R CMD checkDevel使用本仓库的开发版 dplyr当前为1.2.1.9000CRAN使用 CRAN 上已发布的最新稳定版 dplyr。日志目录也遵循这一约定例如amberr的日志分别位于/tmp/workdir/amberr/new/amberr.Rcheck/00install.outDevel与/tmp/workdir/amberr/old/amberr.Rcheck/00install.outCRAN。new/对应新dev版本、old/对应旧CRAN版本这是revdepcheck工具的标准目录约定。正是这种「双版本对照」设计让failures.md能回答一个关键问题某个下游包装不上到底是不是 dplyr 的锅判断标准很直观只有Devel 段报错、CRAN 段正常 → 失败极可能由 dplyr 的开发版变更引入属于Newly brokenDevel 与 CRAN两段都报错→ 失败与 dplyr 的本次变更无关属于In both两段都正常Status: OK却仍被列入报告 → 属于「安装前检查阶段就终止」的Error before installation类。二、逐条读懂 failures.md 的条目结构报告中每个失败包的结构完全一致以amt (0.3.0.0)为例# amt (0.3.0.0) * GitHub: https://github.com/jmsigner/amt * Email: mailto:jsignergwdg.de * GitHub mirror: https://github.com/cran/amt Run revdepcheck::cloud_details(, amt) for more info ## Newly broken * checking whether package amt can be installed ... ERROR Installation failed. See /tmp/workdir/amt/new/amt.Rcheck/00install.out for details. ## Installation ### Develinstallingsourcepackage amt ... ... Error: object select_vars is not exported by namespace:dplyr ERROR: lazy loading failed for package amt### CRAN...DONE (amt)各字段含义如下包名与版本号如amt (0.3.0.0)部分包版本号为NA如CytoML (NA)表示检查环境未能获取到元数据。联系信息GitHub 主页、维护者邮箱、CRAN 镜像供维护者认领问题。Run revdepcheck::cloud_details(, 包名)官方提供的复现入口调用revdepcheck包的cloud_details()可在云端重跑该包的完整检查并下载日志。状态标签分类In both/Newly broken/Newly fixed/Error before installation语义见下节。Installation → Devel / CRAN 两段日志最原始的安装输出是根因分析的唯一权威证据。2.1 四类状态标签的语义结合 revdep/README.md 的索引表其中__1__表示相对 CRAN 版新增的错误计数28 个失败包可归为四类状态含义涉及包In bothDevel 与 CRAN 两版 dplyr 下都安装失败与 dplyr 本次变更无关amberr、bayesdfa、EcoEnsemble、galvanizer、ggmosaic、kerastuneR、multinma、rshift、stoRy、tidyjson、tricolore、TriDimRegressionNewly broken仅 Devel 版 dplyr 下安装失败极可能由 dplyr 开发版变更引入amt、bootnet、FairMclus、GOxploreR、IVPP、kerntools、RcmdrPlugin.RiskDemoNewly fixed检查中同时出现「新修好」的条目如 FairMclus 的依赖检查 NOTE 变为正常FairMclusError before installation尚未进入正式安装阶段即终止或检查环境无法获取包CytoML、DSMolgenisArmadillo、dsTidyverse、dsTidyverseClient、flowWorkspace、loon.shiny、NanoMethViz、pkgstats、quanteda一个值得注意的细节failures.md收录 28 个条目而 revdep/cran.md 的「Failed to check」列表只汇总了 24 个包——被排除的 4 个CytoML、flowWorkspace、NanoMethViz、pkgstats正是版本号为NA且两段日志均为空的条目说明它们在检查环境中根本没能进入正常检查流程。2.2 FairMclus 的「一边新坏、一边新好」FairMclus (2.2.1)是唯一同时出现两个状态标签的包Newly broken安装阶段报object id is not exported by namespace:dplyrNewly fixed原先checking dependencies in R code ... NOTE未使用base、data.table命名空间在开发版下消失。这说明逆向依赖检查并非单向恶化——dplyr 的某些改动会修好旧问题同时可能引入新问题因此failures.md需要同时追踪两条时间线。三、失败根因归类28 个包其实只对应六种病因将 28 个包的安装日志逐条对读后可以发现绝大多数失败可以归入以下六类根因。其中只有第一类7 个包真正与 dplyr 的 API 变更相关其余均为下游依赖、工具链或环境问题。3.1 根因一与 dplyr 强相关已移除的旧 API 仍在被引用这是Newly broken的核心病因共 7 个包报错清一色是object xxx is not exported by namespace:dplyr——即它们调用了曾经由 dplyr 导出、但在开发版中已被彻底移除的函数包引用的已移除对象CRAN 版表现amt (0.3.0.0)select_vars安装成功bootnet (1.6)id安装成功FairMclus (2.2.1)id安装成功GOxploreR (1.2.8)id安装成功IVPP (1.1.1)id安装成功kerntools (1.2.0)id安装成功RcmdrPlugin.RiskDemo (3.2)location安装成功以bootnet为例Devel 日志明确显示Error: object id is not exported by namespace:dplyr Execution halted ERROR: lazy loading failed for package bootnet而同一包的 CRAN 段日志正常收尾于* DONE (bootnet)。两者唯一差异就是 dplyr 版本因此可断定这是 dplyr 开发版移除旧 API 导致的「新破坏」。源码证据NEWS.md 的「Removed」章节完整记录了这三组对象的移除历史id()0.5.0 起弃用2016-06现已移除。官方建议改用vctrs::vec_group_id()若包内通过 NSE非标准求值隐式依赖变量id需要在包内某个文件中加入utils::globalVariables(id)向 R 声明id是列名NEWS.mdselect_vars()与select_vars_()0.8.4 起弃用2020-01现已移除改用tidyselect::vars_select()NEWS.md同批移除的还有rename_vars()、select_var()、current_vars()分别对应tidyselect::vars_rename()、vars_pull()、peek_vars()location()与changes()1.0.0 起弃用改用lobstr::ref()NEWS.md。从当前源码看dplyr 已不再提供这些符号在R/目录中搜索select_vars只命中内部函数vars_select_syms()见 R/colwise-select.R而列选择逻辑统一委托给tidyselect::vars_select()见 R/colwise.RNAMESPACE中也不再导出id。这正是下游包报not exported的直接原因。迁移建议如果你维护的包依赖这些函数应按以下对照迁移已移除对象现代替代备注id()vctrs::vec_group_id()生成分组标识当前 dplyr 生态中consecutive_id()见 R/consecutive-id.R与row_number()见 R/rank.R也是常见的替代方案select_vars()/select_vars_()tidyselect::vars_select()字符向量 选择帮助器rename_vars()/select_var()/current_vars()tidyselect::vars_rename()/vars_pull()/peek_vars()—location()/changes()lobstr::ref()对象内存结构分析3.2 根因二与 dplyr 无关purrr 的at_depth已被移除amberr、galvanizer、kerastuneR、stoRy、tidyjson 五个包全部报同一个错Error: object at_depth is not exported by namespace:purrr关键在于这五个包在Devel 与 CRAN 两段日志中都报同样的错属于In both。也就是说无论 dplyr 是哪个版本它们都装不上问题根源在下游包对purrr::at_depth()的依赖与 dplyr 的本次变更无关。这类条目出现在failures.md的意义在于完整记录生态现状避免维护者误以为是 dplyr 引入的回归。3.3 根因三第三方依赖缺失或不可用bayesdfa (1.3.4)与TriDimRegression (1.0.3)两段日志均为Error in loadNamespace(x) : there is no package called rstantools说明检查环境缺少其配置期依赖rstantools属于环境准备问题In both。loon.shiny (1.0.3)checking package dependencies ... ERROR / Packages required but not available: loon, loon.ggplot。这两个依赖未收录在 CRAN检查环境无法安装属于Error before installation。3.4 根因四编译期资源或工具链问题EcoEnsemble (1.1.2)与multinma (0.8.1)两者都是含 Stan/C 代码的包日志最终均停在g: fatal error: Killed signal terminated program cc1plus compilation terminated. make: *** [.../Makeconf:209: stanExports_....o] Error 1 ERROR: compilation failed for package EcoEnsemble从日志可以推断编译进程cc1plus被系统直接终止这是典型的资源受限如内存不足触发 OOM-killer或编译配额限制导致的失败且两段日志完全一致In both与 dplyr 无关。rshift (3.1.2)Rust 工具链版本错配。日志显示使用cargo 1.75.0构建时error: failed to parse lock file at: .../Cargo.lock Caused by: lock file version 4 requires -Znext-lockfile-bump make: *** [Makevars:28: rust/target/release/librshift.a] Error 101即其Cargo.lock的格式版本高于当前 cargo 版本所能解析需要升级 Rust 工具链或重建 lockfile与 dplyr 无关In both。3.5 根因五下游可视化包的 API 冲突ggmosaic (0.3.3)object is.waive not foundIn both说明其依赖的 ggplot2 版本移除了内部对象。tricolore (1.2.4).onLoad failed in loadNamespace() for ggtern错误为ggplot2::element_line object properties are invalid: lineend must be character or NULL, not S3arrow即ggtern与当前 ggplot2 版本的对象属性校验不兼容In both。3.6 根因六安装前检查即终止Error before installationCytoML、flowWorkspace、NanoMethViz、pkgstats版本号NADevel/CRAN 两段日志均为空未进入实际检查。DSMolgenisArmadillo、dsTidyverse、dsTidyverseClient日志完整走完checking ... OK并输出Status: OK却在「安装前」被标记——即这两个 DataSHIELD 相关包本身没问题是报告归类/收集中途终止。quanteda (4.3.1)Devel 段日志为空CRAN 段显示Status: OK。四、如何用这份报告排查自己的包4.1 三步定位法查状态标签Newly broken→ 优先怀疑 dplyr 开发版变更In both→ 与 dplyr 无关转向第三方依赖。对读 Devel / CRAN 两段日志找到 Dev 段独有、CRAN 段没有的那条Error:行它就是破坏源。对照 NEWS.md在开发版文件顶部章节与历史版本的「Removed / Deprecated」章节中检索该报错对象名确认移除时间线与替代函数。4.2 复现与深入排查报告为每个包都给出了复现指令revdepcheck::cloud_details(, amberr)revdepcheck::cloud_details()是revdepcheck包提供的云端复现接口将包的完整检查在隔离环境中重跑并返回日志适合验证「换一台机器/换一个 dplyr 版本」后失败是否仍然复现。本地复现的标准流程则是install.packages(revdepcheck) library(revdepcheck) revdep_check() # 检查全部逆向依赖 revdep_report() # 重新生成 revdep/ 下的报告注意本仓库的revdep/目录是只读的检查产物不建议也不需要通过修改仓库文件来「修复」报告本身。4.3 数据规模与时效性说明本报告对应的 dplyr 版本为1.2.1.9000开发版见 DESCRIPTION检查于该版本发布前执行。表内所有「能装/不能装」结论仅对本次检查环境成立——例如bayesdfa缺少rstantools、loon.shiny缺少loon都取决于云端环境的依赖安装策略不能推广为「这些包永远装不上」。引用本报告数据时应同时注明版本与检查环境Ubuntu 24.04、R 4.5.1见日志头部。五、给下游包维护者的行动清单如果状态是Newly broken且报错为not exported by namespace:dplyr按第三节的迁移对照表替换id()、select_vars()、location()等旧 API升级tidyselect、vctrs依赖并重新检查。如果状态是In both无需等待 dplyr 侧修复直接排查 purrr 版本、rstantools 等环境依赖、C/Rust 工具链或下游绘图包的版本冲突。如果包内通过 NSE 引用列名如id即使不直接调用id()函数也会因dplyr不再导出该符号而在懒加载阶段报错按 NEWS.md 的建议加入utils::globalVariables(id)即可。定期跟踪 NEWS.md 的 Removed 章节dplyr 遵循「先弃用、后移除」的生命周期策略如id()自 0.5.0 弃用多年后才移除提前迁移可避免在开发版上「突然」失败。六、小结revdep/failures.md不是一份简单的报错堆砌而是一份经过设计的兼容性证据链双版本Devel/CRAN对照日志 状态标签 复现指令三者结合让任何人无论是 dplyr 维护者还是下游包作者都能在几分钟内判断「这次失败是否由 dplyr 引起」。在本轮检查中真正由 dplyr 开发版 API 移除引起的Newly broken只有 7 个包集中在id()、select_vars()、location()三组早已弃用的符号上其余 21 个条目则如实记录了第三方依赖、工具链与编译环境的生态现状。对下游维护者而言这份报告加上 NEWS.md 的 Removed 章节就是一份现成的迁移路线图。赞分享数据分析【免费下载链接】dplyrdplyr: A grammar of data manipulation项目地址https://gitcode.com/gh_mirrors/dp/dplyr点击查看免费下载相关推荐ggplot2 反向依赖检查失败报告深度解读从 revdep/failures.md 到生态影响评估ggplot2 反向依赖检查失败报告深度解读从 revdep/failures.md 到生态影响评估 本文以 ggplot2 仓库 revdep/failur数据可视化dplyr 反向依赖检查revdep报告解读172 个生态级问题与 API 变迁全景dplyr 反向依赖检查revdep报告解读172 个生态级问题与 API 变迁全景 dplyr 是 R 生态中数据操作语法A Grammar of数据分析ggplot2 反向依赖检查Revdep报告解读从 problems.md 看 API 变更对下游包的影响ggplot2 反向依赖检查Revdep报告解读从 problems.md 看 API 变更对下游包的影响 本文以 ggplot2 仓库 revdep/p数据可视化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考