r-cran-status

CRAN 软件包状态

检查软件包的提交／审核状态、某个历史版本的去向（例如 {package} {version}，如 btw v1.4.0），或该软件包当前在 CRAN 各测试平台上的 R CMD check 结果。

“CRAN 状态”可能指两个不同的问题：

• 提交状态：该软件包（或版本）是否正在／曾在审核中、已发布、已归档或被拒绝？请参阅“提交状态”。
• 检查结果：已发布的版本是否在所有平台上通过 R CMD check，还是有可能导致其被移除的 WARN/ERROR/NOTE 标记？请参阅“检查结果”。

CRAN 的服务器是共享的免费资源。切勿并行发送请求或在短时间内循环请求——请在请求之间稍作等待（例如 sleep 1），一旦找到匹配项就停止循环，并避免重新获取本次会话中已检查过的页面。

工作流

1. 如果未提供软件包名称，请询问软件包名称。也可以提供版本（例如 btw v1.4.0 或 btw 1.4.0）；去掉开头的 v。
2. 判断用户询问的是哪个问题：
   • 提供了版本，或请求提到提交、审核、队列或拒绝／归档 → 提交状态。
   • 请求提到检查、R CMD check、WARN/ERROR/NOTE 或平台／flavor → 检查结果。
   • 请求提到 win-builder、check_win_devel() 或提交是否已送达 → Win-Builder。
   • 如果确实无法判断（例如只说“检查 x 的 CRAN 状态”），请询问具体指哪一项，或检查两项并分别报告。
3. 按照下面的相关章节操作并报告结果。

提交状态

1. 先检查当前已发布的版本（见下文）。
2. 如果用户未指定版本，或指定版本与当前版本一致：报告该版本是当前已发布版本。除非该版本不在 PACKAGES 中，否则跳到第 5 步；若不在，则继续第 3 步。
3. 如果本次对话中先前的检查已在某个阶段或审核者文件夹中找到该软件包，则先检查该文件夹，再按流程顺序继续向后检查（见“CRAN 审核阶段”）——不要从头重新扫描。否则，扫描所有阶段和审核者文件夹。
4. 搜索 incoming/ 阶段文件夹（见下文）。
5. 搜索审核者分配的文件夹（见下文）。
6. 如果用户指定了版本，且该版本与当前已发布版本不同（或软件包尚未发布），请检查 CRAN Archive 中是否有该版本（见下文）。
7. 报告结果（见“提交状态结果报告”）。

CRAN 审核阶段

以下按典型流程顺序列出——软件包通常会从上到下依次流转，但并非每个软件包都会经过所有阶段：

• inspect / newbies：等待初步人工检查（newbies 面向首次提交者）
• pending：等待进一步审核
• human/<initials>：已分配给 CRAN 审核者
• pretest：自动检查正在（重新）运行
• waiting：CRAN 正在等待维护者回复（维护者回复后会返回 pretest）
• recheck：反向依赖检查
• publish：已获批准，等待发布
• archive：已拒绝

检查待处理阶段文件夹

将 {package} 替换为实际的软件包名称。如果已知最后所在阶段，则从该阶段开始（见“提交状态”第 3 步）；否则从 inspect 开始：

for stage in inspect newbies pending pretest waiting recheck publish archive; do
  curl -Ls "https://cran.r-project.org/incoming/$stage/" |
    grep -Eio '[^"]*{package}[^"]*' &&
    echo "Stage: $stage" && break
  sleep 1
done

检查审核者分配的文件夹

审核者姓名缩写文件夹（例如 human/KH）会随着 CRAN 团队变化，因此请从 incoming/ 列表中发现这些文件夹，而不要使用固定列表：其中任何不属于上述阶段名称的文件夹都是审核者文件夹。

reviewer_folders=$(
  curl -Ls "https://cran.r-project.org/incoming/" |
    grep -Eio '<a href="[^"]+/">' |
    sed -E 's/<a href="([^"]+)\/">/\1/' |
    grep -Ev '^(inspect|newbies|pending|pretest|publish|recheck|archive|waiting|special)$'
)

for stage in $reviewer_folders; do
  curl -Ls "https://cran.r-project.org/incoming/$stage/" |
    grep -Eio '[^"]*{package}[^"]*' &&
    echo "Stage: human/$stage" && break
  sleep 1
done

检查软件包是否已发布

curl -Ls https://cran.r-project.org/src/contrib/PACKAGES |
  awk -v pkg="{package}" '
    $0 == "Package: " pkg { found=1 }
    found && /^Version:/ { print; exit }
  '

打印出的 Version: 行表示当前的 CRAN 版本。请记住该版本——稍后需要用它说明用户请求的旧版本是否已被该版本“取代”。

在 CRAN Archive 中检查特定版本

被取代的版本会从 src/contrib/ 移至按包划分的归档文件夹。这里的 Archive 与上文的 archive incoming/ 阶段无关（前者表示“已拒绝”，此处表示“因被取代而成为旧版本”）。

curl -Ls "https://cran.r-project.org/src/contrib/Archive/{package}/" |
  grep -Eio '[^"]*{package}_{version}\.tar\.gz[^"]*'

如果存在匹配的 .tar.gz 文件名，就表示该确切版本曾经发布过，之后已被取代。

报告提交状态结果

• 未请求特定版本：
  • 在 PACKAGES 中：报告该包已发布，并注明当前版本。
  • 否则，如果在 incoming/ 或审查者文件夹中找到：报告文件夹名称及上文阶段列表中的含义。
  • 否则：报告在 CRAN 的提交队列或索引中未找到该包。
• 请求了特定版本：
  • 与 PACKAGES 中的当前版本匹配：报告该版本是当前发行版。
  • 否则，如果在 CRAN Archive 中找到：报告该版本曾经发布过，且已被 PACKAGES 中的当前版本取代，例如“可在归档中获取，已被 v1.5.0 取代”。
  • 否则，如果在 incoming/ 或审查者文件夹中找到该包（任意版本）：报告所在阶段，并说明所请求的版本并非过去发行的版本。
  • 否则：报告未找到所请求的版本（当前版本、归档版本或审查中的版本均未找到）。

检查结果

CRAN 会发布每个已发布包按平台划分的 R CMD check 结果，网址为 https://cran.r-project.org/web/checks/check_results_{package}.html。WARN 或 ERROR 结果持续约 2-4 周以上，可能会导致 CRAN 将其归档。

获取并简化结果表：

curl -Ls "https://cran.r-project.org/web/checks/check_results_{package}.html" |
  grep '<tr> <td>' |
  sed -E 's/<[^>]+>/ /g' |
  awk '{print $1": "$NF}'

每行会输出一条 flavor: STATUS，例如：

r-devel-linux-x86_64-debian-clang: OK
r-oldrel-windows-x86_64: ERROR

状态为 OK、NOTE、WARN 或 ERROR。对于任何状态不是 OK 的 flavor，同一页面下方的“Check Details”部分提供完整的失败输出：再次获取页面但不移除标签，并阅读失败 flavor 的 Version: / Check: / Result: 行之后采用 <pre> 格式的部分。

404 表示没有 CRAN 检查历史记录，可能是当前尚未发布。请改为检查提交状态。

报告检查结果

• 所有 flavor 均为 OK：报告该包在所有平台上均通过检查。
• 任一 flavor 为 NOTE/WARN/ERROR：列出受影响的 flavor 和状态，根据“Check Details”总结失败原因，并说明持续出现 WARN/ERROR 可能导致归档。
• 页面返回 404：报告不存在检查结果；改为检查并报告提交状态。

Win-Builder

Win-builder（win-builder.r-project.org）会在 Windows 上对通过 devtools::check_win_devel()（或 check_win_release() / check_win_oldrelease()）提交的软件包运行 R CMD check：系统会通过匿名 FTP 将 tarball 上传到 ftp://win-builder.r-project.org/<flavor>/（R-devel、 R-release 或 R-oldrelease），并通常会在 15-30 分钟内将结果通过电子邮件发送到 DESCRIPTION 中的维护者地址。本地显示成功消息只表示上传命令已完成——请在服务器上 确认是否已收到。

1. 上传确认（权威依据）。 tarball 应列在相应 flavor 的 FTP 文件夹中：

   curl ftp://win-builder.r-project.org/R-devel/
   

   列出即表示已上传并进入队列。服务器时间戳采用欧洲时间（CEST/CET）——与本地提交时间比较时 请换算时差。

2. 进度。 win-builder 取走文件后，文件会出现在预检列表中：

   curl -Ls https://win-builder.r-project.org/incoming_pretest/ |
     grep -i {package}
   

   条目格式为 {package}_{version}_{yyyymmdd}_{hhmmss}，仅在检查开始后才会出现；日志位于 每个条目中（例如 00check.log）。条目会保留数月——请根据版本和日期匹配， 不要只看软件包名称。

注意事项：

• 没有 incoming_pretest 条目 ≠ 上传失败——条目会晚于 FTP 列表出现，而 FTP 列表是确认文件到达的权威依据；队列可能会堵塞数小时，列表中的积压情况可以反映这一点。
• tarball 仍在列表中时，不要建议重新提交——它已在队列中，重复提交不会加快处理速度。
• tarball 已消失但没有收到电子邮件？运行很可能已经完成；请检查维护者的垃圾邮件文件夹，以及 incoming_pretest/ 中是否有版本匹配的近期条目。数小时后仍没有任何消息 → 请联系 R-package-devel，而不要重新提交。