Lib.rs

数据处理

lib.rs不仅仅显示crates.io的数据。许多crate的元数据不完整，例如缺少分类或关键词，这有助于找到crate。有时crate作者指定的元数据是错误的（例如，解析分类的目的是经常被误解，或者被分叉的crate的仓库链接仍然指向上游仓库而不是分叉，等等）。crates.io计数的下载次数没有任何限制或反垃圾邮件措施，因此它们受到来自网络爬虫和未缓存的CI构建的自动化下载的偏见。

为了使搜索更好地工作，并且crate页面显示更多有用的信息，lib.rs将crates.io的数据与github.com、docs.rs、rustsec.org、rustaceans.org、cargo-crev仓库、cargo-vet注册表以及自己的数据集和分析数据相结合。这意味着组合的数据不仅来自crate作者，而且应理解为lib.rs的解释，而不是crate作者意图的内容。

lib.rs经常使用启发式方法来完成和修复数据。大多数数据质量问题都报告在维护者仪表板上。

• 如果crate缺少关键词，它们将从crate的描述、readme、源代码和github元数据中抓取。这有时会挑选出不是最相关的词语。crate作者可以通过在keywords字段中填写Cargo.toml来防止这种情况。关键词被规范化为连字符形式，并且一些拼写变体和近似同义词被正规化。

• lib.rs的分类与crates.io略有不同。一些分类已经被合并，因为单独的分类中crate太少，或者经常相互混淆。一些分类已经被扩大，以容纳没有专用分类的crate。

  • 删除了api-bindings和external-ffi-bindings。这些crate现在位于特定主题的分类中（按它们的目的分类，而不是按它们是什么分类）。
  • 将本地化合并到国际化。
  • 将无人机和UAV合并到机器人技术。
  • 将游戏引擎合并到游戏开发。
  • 将图形合并到图像。
  • 将freebsd和linux合并到unix-apis。
  • 将no-alloc合并到no-std。
  • 将multimedia::encoding合并到其他多媒体子分类。
  • 将编译器扩展到通用编程语言。
  • 将计算机视觉扩展到机器学习。
  • 将macos-apis扩展到包括iOS和其他苹果平台。
  • 将神经科学扩展到生物学。

• 如果一个crate缺少lib.rs使用的分类，或者有常见的混淆分类（例如，解析与parser-implementations），则lib.rs将尝试根据crate的关键词、功能、依赖关系和相似crate的分类使用模糊逻辑来推断分类。有时如果启发式方法没有选择正确的分类，则会手动覆盖分类。在大多数情况下，作者可以通过在Cargo.toml中填写categories和keywords字段来防止这种情况。分类问题在维护者仪表板中标记。

• lib.rs用户GitHub的贡献者洞察来显示对项目贡献最多的用户。因为crates.io已经弃用了authors元数据字段，所以这些作者的名称不会显示，除非它们似乎是团队或组织的名称。如果可以与GitHub账户匹配，则会显示个人作者，然后lib.rs使用GitHub中的名称。由于数据被缓存在GitHub API配额内，因此可能需要一段时间才能更新。

• 如果crates.io上的crate缺少README文件，lib.rs将搜索其仓库中的README文件，或显示来自src/lib.rs的文档注释。

• readme中的链接，如果指向crates.io上的crate页面，将被重写为等效的lib.rs页面。图片将通过一个图像调整大小服务进行代理。README中的相对链接取决于文件在其仓库中的特定提交位置。因此，在发布的crate中有时会丢失此上下文，因此相对链接可能会损坏。对Rustdoc特定的markdown语法有部分支持，用于文档链接。

• 如果crate没有指定仓库URL，lib.rs将检查crate所有者是否在github.com上为该crate有仓库。

• 如果crate被rustsec.org或cargo-crev审查员标记为不维护，crate页面将显示不维护徽章。

• cargo-vet diff审查如果可以合并来自同一源的安全部署diff，以覆盖crate的所有版本，则将显示为完整审查。

• 如果crate的GitHub仓库被存档，crate页面将反映这一点。

• 多个crate之间的关系是根据它们仓库的目录结构（如果它们共享monorepo）、命名方案（例如，具有_derive后缀）以及在crates-io上的共享所有者来推断的。

• 一些数据基于crate描述和readme中的文本，例如crate是否为保留的、已弃用的或内部的。

• crate是否被标记为“dev”或“build”依赖项取决于它在[dev-dependencies]和[build-dependencies]中使用的频率，与常规依赖项部分相比。

• lib.rs有一个手动管理的已弃用/过时crate列表（例如tokio v0.1或futures-preview）。如果库失去了大多数用户（从crate中删除，或大多数使用它们的crate变得不再维护），则可能也会将其标记为已弃用。

• 如果crate缺少rust-version字段，则根据crate及其依赖项的cargo check的成功和失败来估计最低支持的Rust版本信息。

• 下载次数经过过滤，以去除噪声、可疑的异常值和已知的垃圾邮件/操纵事件。

• 根据src/lib.rs中是否存在std/no-std Cargo功能或属性来推断no-std支持。

• 手动禁止用户进行名称抢注。

未来可能会扩展源和算法列表。有关排名和过时依赖项的逻辑也请参阅。