DORA Hub 实战指南用一行 YAML 复用、发布与锁定 dora 节点【免费下载链接】doraDORA (Dataflow-Oriented Robotic Architecture) is middleware designed to streamline and simplify the creation of AI-based robotic applications. It offers low latency, composable, and distributed dataflow capabilities. Applications are modeled as directed graphs, also referred to as pipelines.项目地址: https://gitcode.com/GitHub_Trending/do/doraDORADataflow-Oriented Robotic Architecture以有向图pipeline组织机器人应用而Dora Hub是它面向节点复用的包管理系统在dataflow.yml里写一行hub: dora-yolo^0.5dora build就会像cargo/npm解析依赖一样把该引用解析到精确提交、注入类型化输入输出契约并完成构建。本文以 guide/src/hub/overview.md 为主线系统讲解 Hub 的解析模型、hub:引用语法、节点清单manifest编写、可复现构建、发布流程与自定义索引并结合作品仓库内 CLI 与hub-client的源码实现进行纵深印证帮助你同时掌握“消费节点”与“发布节点”两条完整链路。什么是 Dora Hub在引入 Hub 之前在数据流中复用一个节点通常意味着把它的源码 vendor 进你的仓库或手写一条path:/git:条目再自行管理版本。Dora Hub 改变的是这一体验——它让“复用”变成一行 YAMLnodes: - id: detector hub: dora-yolo^0.5 # ← 从 Hub 解析锁定到精确提交并做契约校验 inputs: image: camera/image outputs: - bboxdora build会完成四件事把dora-yolo^0.5解析到一个已发布的具体版本、将其固定到精确的 commit、把该节点清单中声明的输入/输出类型契约注入到校验流程然后构建它——机制上与cargo或npm解析依赖一致。⚠️稳定性说明hub:功能目前标记为unstable其行为可能在未来的版本中变化但节点清单格式本身apiVersion: 1是稳定的即使不使用 Hub 也很有用详见 编写节点清单。从源码结构看这一能力对应的核心实现位于 binaries/cli/src/command/build/hub.rsresolve_hub_nodes会在构建派发前把每个hub:节点重写desugar为具体的 git 源节点或二进制下载节点并完成契约注入与锁文件记录其模块注释明确写道“CLI 在派发前把每个hub:节点重写成具体的 git 源节点……下游的协调器、守护进程与锁文件看到的是一个普通的 git 节点”。Hub 的设计模型Hub 是一个面向 dora 节点的包管理器刻意采用 cargo 风格核心模型可以概括为五条按数据流解析无全局安装。不存在dora hub install这种修改机器的全局安装操作该命令在 install.rs 中是一个刻意设计的错误桩用一条错误信息引导你回到“把hub:写进 YAML然后dora build”的正确路径。节点是某个数据流的依赖你在 YAML 里加hub:dora build就解析它。git 支撑的索引而非制品上传。发布时只是新增一条很小的索引条目指向节点源码的某个 git commit不上传 tarball。默认索引是dora-rs/dora-hub公共目录git 仓库。默认源码分发。解析后的节点会在其锁定的 commit 处被 clone并在运行它的机器上构建。节点可以可选地为某个平台附带预编译二进制见 自定义与企业索引。可复现。dora build --write-lockfile记录精确 commitdora build --locked逐字节复现。详见 可复现构建。端到端类型化。已发布的节点在其清单中携带 dora 输入/输出契约接线错误会在dora build/dora validate阶段就失败而不是等到运行时。hub:引用语法与版本解析一个hub:值的完整形式是[namespace/]nameversion-requirementhub: dora-yolo^0.5 # 官方命名空间dora-rs——裸名称 hub: dora-rs/dora-yolo^0.5 # 等价的全限定写法 hub: acme/lidar~2.1 # 第三方命名空间 hub: dora-vad # 没有 req → 任意版本最新的未被 yank 的版本裸名称是官方dora-rs/命名空间的简写。这一点在源码中有精确印证libraries/hub-client/src/reference.rs 的PackageRef::parse把dora-yolo^0.5解析为namespace dora-rs、name dora-yolo其测试用例bare_name_is_official_shorthand直接断言了这一行为官方命名空间常量OFFICIAL_NAMESPACE dora-rs定义于 libraries/hub-client/src/lib.rs。版本要求部分采用标准的 semver/Cargo 范围语法解析时选取满足要求且未被 yank 的最高版本写法匹配范围^0.50.5.0, 0.6.0caret对0.x系列minor 视为破坏性变更^1.21.2.0, 2.0.0~2.12.1.0, 2.2.00.5, 0.7显式范围1.2.3精确该版本*或省略任意版本预发布版本如0.6.0-rc1只有在该要求本身点名预发布版本时才会被匹配遵循 Cargo 约定。PackageRef的解析同样把“无即*”写进了实现None (reference.trim(), VersionReq::STAR)。建议先约束好版本范围再用锁文件锁定见下文“可复现构建”。没有锁文件时每次dora build都会重新解析到满足条件的最新版本。使用 Hub 节点消费侧实战在数据流中引用 Hub 节点就是把path:/git:替换为hub:nodes: - id: detector hub: dora-yolo^0.5 inputs: image: camera/image outputs: - bbox - id: camera hub: opencv-video-capture^0.3 outputs: - image注意hub:与同一节点上的path:、git:、build:以及branch/tag/rev字段互斥——Hub 包已提供这些全部信息。你仍然像往常一样书写节点的inputs/outputs接线但端口的类型来自已发布的清单。搜索目录dora hub search yolo # 按名称 / 描述 / 关键词匹配 dora hub search --category ml-inference # 按类别浏览 dora hub search lidar --platform linux-x86_64 dora hub search # 列出全部搜索会覆盖所有已配置的索引并输出namespace/name version — description (categories)使用每个包的最新版本。search.rs 的实现显示它会遍历所有 catalog 中每个包跳过被 yank 的版本再按类别、平台仅当清单声明了非空platforms时与查询子串过滤。查看包详情dora hub info展示一个包的类型化契约、配置面与可直接粘贴的示例——接线前先读它你就知道端口与类型dora hub info dora-yolo # 最新版本 dora hub info dora-yolo0.5.2 # 指定版本 dora hub info acme/lidar^2 # 一个版本要求输出内容包括版本若适用会带(yanked)标记、描述、类别、支持平台、运行时python/rust/c/cpp、类型化输入与输出、环境变量以及示例片段对应清单中的example字段。任一上述命令加--offline只使用本地缓存不访问网络。构建与校验解析发生在dora build/dora validate/dora run时——没有独立的 fetch 步骤dora validate dataflow.yml # 解析 hub 节点检查接线与类型不构建 dora build dataflow.yml # 解析、固定并构建每个节点 dora run dataflow.yml # 构建 运行本地由于已发布节点在其清单中携带输入/输出类型常规的类型检查管线同样作用于它把BoundingBox输出接到期望Image的输入上会在组合阶段compose time就带着生产者/消费者 URN 失败任何进程都不会启动。你在数据流中自己的类型注解始终优先于清单中的声明。构建的是什么一个hub:节点会被降级desugar为固定的git:节点解析器在发布的确切 commit 处 clone 节点源码并在构建它的机器上运行其build命令例如pip install .、cargo build --release。对于为你的平台附带预编译二进制的节点解析器改为下载该制品并做 sha256 校验而不是 clone——见 自定义与企业索引 的“二进制分发”一节。build/hub.rs 中的resolve_node_bytes展示了这一抉择逻辑条目带binary列表时若命中当前平台os-arch精确匹配则走NodeBytes::Binary未命中但有fallback-git则退化为源码构建两者皆无则直接报错“no prebuilt binary for this platform”。同时它会把每条 git 源记录GitSource含commit_hash、subdir与hub溯源标记合并进构建的git_sources与锁文件把二进制 pinurl sha256写入锁文件供--locked精确复现。重型构建发生在节点运行的地方因此资源受限设备上建议采用“在宿主机构建、再交付制品”的策略参见 节点清单的构建位置建议 与 离线构建与源码镜像dora hub fetch。本地覆盖一个节点迭代消费中的节点时可以不编辑 YAML、不发布任何东西把单个包指向本地 checkoutdora build dataflow.yml --hub-override dora-yolo../my-fork/dora-yolo这是一个仅限本地构建的内环工具不能与--write-lockfile或分布式构建组合。从源码看--hub-override的处理路径build/hub.rs 中的overrides分支会从本地 checkout 读取清单并完整校验、仍执行契约检查然后把该节点 desugar 为本地path:节点同时记录一个“本地源码被信任”的提示。如果 override 键没有匹配到任何 hub 节点你会收到一条显式警告而不是被静默忽略。编写节点清单dora-node.yml节点清单dora-node.yml是一个可复用 dora 节点的类型化、带版本描述入口点、构建命令、类型化输入/输出契约与配置面。正是它把“一个代码文件夹”变成“别人可以用一行 YAML 发现并接线的节点”。清单只承载语言原生清单无法表达的内容——dora 契约与 dora 接线名称、版本与依赖仍保留在pyproject.toml/Cargo.toml中清单不会重复它们。完整示例# dora-node.yml — 与 pyproject.toml / Cargo.toml 放在一起 apiVersion: 1 # 清单 schema 版本当前为 1 name: dora-yolo # 默认取 [project].name / [package].name namespace: dora-rs # 索引命名空间 一个 GitHub 组织/用户 description: YOLO object detection on camera frames categories: [ml-inference] # 取自固定类别列表 keywords: [vision, detection, yolo] runtime: python # python | rust | c | cpp entrypoint: dora-yolo # 运行什么相对于节点工作目录 build: pip install . # 如何构建在工作目录中运行 platforms: [] # 可选白名单例如 [linux-x86_64, # linux-aarch64]空 全部 dora: 0.4 # 可选的支持的 dora 版本范围 inputs: image: type: std/media/v1/Image # 类型 URN见“类型化契约” required: true description: BGR frame to run detection on outputs: bbox: type: std/vision/v1/BoundingBox description: detected bounding boxes # 节点可以有零输入源或零输出汇 env: # 配置面文档化 类型化 MODEL: default: yolov8n.pt description: model weights file CONFIDENCE: type: float default: 0.4 types: {} # 可选的自定义类型定义以类型 URN 为键 # 没有时省略 example: | # dora hub info 展示的片段 - id: detector hub: dora-yolo^0.5 inputs: image: camera/image outputs: - bbox字段参考字段是否必填说明apiVersion是清单 schema 版本当前为1name可默认回退到[project].name/[package].name按 PEP 503 规范化namespace是索引键为namespace/name等于一个 GitHub 组织/用户runtime是python|rust|c|cppentrypoint是工作目录内的相对路径——不允许绝对路径不允许..build推荐构建命令在工作目录中运行pip install .、cargo build --release、cmake 调用等inputs、outputs是可为空汇无输出源无输入inputs.*.type等推荐类型 URN省略则端口无类型校验跳过它platforms、dora推荐平台白名单按os-arch形态校验驱动dora hub search --platform过滤 dora 兼容范围description、categories、keywords推荐驱动dora hub searchenv、types、requirements、example可选配置面、随包类型、声明的需求、文档片段清单 schema 以 JSON Schema 形式随仓库发布在 libraries/core/dora-node-schema.json可用于编辑器自动补全该文件由 libraries/core/src/bin/generate_schema.rs 生成。清单解析器在 libraries/core/src/manifest/mod.rs 中文件名常量MANIFEST_FILENAME dora-node.yml与deny_unknown_fields严格反序列化都在这里未知字段例如清单里手写version:会被直接拒绝——版本一律来自原生清单或--version。entrypoint 校验entrypoint被校验为节点工作目录内的相对路径——绝对路径和..分量都会被拒绝Python托管环境PATH上的 console script[project.scripts]中的名称例如dora-yolo。Rust / C / C构建产物例如target/release/dora-yolo或build/lidar。当从 Hub 包解析时entrypoint 只在节点自己的工作目录或托管环境中查找——不搜索宿主机的$PATH因此一个笔误会响亮地失败而不是静默执行宿主机上的某个二进制。类型化契约输入/输出类型复用 dora 既有的类型 URN 体系std/category/v1/TypeName、嵌套结构 schema、参数化类型与加宽兼容图。当hub:或相邻的path:节点被组合时清单的inputs/outputs类型会呈现为节点的input_types/output_types随后走常规校验管线dora validate dataflow.yml # 生产者/消费者 URN 兼容性、字段差异 dora build dataflow.yml # 同样的检查在任何进程启动之前把std/vision/v1/BoundingBox输出接到期望std/media/v1/Image的输入上——这类不匹配在组合阶段就会以生产者/消费者 URN 的形式失败。数据流作者的注解始终优先于清单的声明。随包携带自定义类型节点可以随包发布自己的类型定义YAML 形态与 libraries/core/types 下的std/*/v1.yml一致但它们必须位于包自己的命名空间之下——std/及其他命名空间会被拒绝namespace: acme types: acme/lidar/v1/PointCloud: arrow: Struct fields: - name: x type: Float32 - name: y type: Float32 outputs: cloud: type: acme/lidar/v1/PointCloud随包类型在解析时被加载进数据流的类型注册表因此消费者可以在自己的端口检查中引用它们。在 build/hub.rs 中这对应shipped_type_issues与registry.add_user_type的调用序列——更重要的是解析器还会校验索引条目自声明的namespace必须与它实际被抓取的命名空间一致防止恶意条目借namespace: victim之类的声明绕过跨命名空间防护。用dora hub init脚手架dora hub init会在你的pyproject.toml或Cargo.toml旁写出一个起步版dora-node.yml并尽可能预填它能读到的内容名称、来自[project.scripts]/ 二进制目标的 entrypoint、描述cd my-node dora hub init # 写出 ./dora-node.yml dora hub init path/to/node # 或指定某个目录填好inputs/outputs类型与env后可以单独校验清单dora validate --node-manifest dora-node.yml本地开发无需索引你不需要发布任何东西就能获得契约校验。一个与普通path:节点相邻的dora-node.yml会被自动拾取nodes: - id: detector path: target/release/detector # dora-node.yml 位于节点的根目录 inputs: image: camera/imagedora build/dora validate读取相邻清单、注入其类型化端口并检查你的接线——与 Hub 消费者得到的校验完全一致。这就是编写节点契约时推荐的内环流程。该机制的实现位于 libraries/core/src/manifest/inject.rs它会扫描数据流中带相邻dora-node.yml的path:节点。构建位置建议从源码构建的节点意味着运行它的机器上要发生编译。dora 的多守护进程流程中每个 daemon 构建自己的节点——在笔记本上没问题但在资源受限设备上可能慢到无法接受甚至失败例如 Jetson 编译重型节点可能热降频或内存耗尽目标机编译默认适用于性能足够的机器与轻量节点。宿主机构建再交付嵌入式推荐在性能足够的机器上为目标架构构建再通过离线缓存流程部署结果让机器人永远不编译。经验法则不要在受限的 daemon 上跑重型构建。可复现构建锁文件与--locked^0.5是一个范围。不固定的话每次dora build都会重新解析到最新的匹配版本两次构建可能不同。锁文件记录每个节点解析到的精确 commit对二进制节点则是精确制品使构建跨机器、跨时间可复现——与Cargo.lock、package-lock.json是同一个模型。写出锁文件dora build dataflow.yml --write-lockfile这会解析每个hub:以及git:节点、构建数据流并在数据流旁写出名为dataflow-stem.dora-lock.yaml的锁文件。请把它与数据流一起提交。锁文件按节点记录解析到的git 源——仓库、精确commit_hash与subdir外加 hub溯源信息包name、解析到的version、manifest_digest或解析到的二进制源——platform、url、sha256——用于随包携带预构建制品的节点。此外它还记录数据流源图的descriptor_fingerprint用于检测 YAML 是否在锁文件写出之后发生了变化。从锁文件构建dora build dataflow.yml --locked--locked是严格模式每个hub:节点必须出现在锁文件中且仍然有效否则构建失败而不是现场重新解析。它重建精确固定的 commit/制品——在 CI 与部署目标上使用它确保“你部署的就是你测试的”。--locked还会重新做完整性检查数据流指纹必须与锁文件一致YAML 没有漂移二进制节点的制品按其sha256重新校验如果某个已发布索引条目的清单在你锁定之后被重写其manifest_digest不再匹配--locked会失败——你锁定的契约变了。而仅源 pin被重写则告警并继续使用锁文件中的 pin。在 build/hub.rs 中可以看到--locked的严格路径无 pin 的 hub 节点在任何索引抓取之前就快速失败提示dora build --write-lockfileresolve_locked_git/resolve_locked_binary会逐一核对 provenance 名称与版本是否仍满足要求、索引条目是否仍存在yank 时告警、锁定的 commit/artifact 是否与索引一致、以及manifest_digest是否被重写二进制 pin 还被要求必须是https://URL 与 64 位十六进制 sha256防止被篡改的锁文件绕过守护进程的校验门。dora validate是best-effort不是 strict存在锁文件时它使用锁文件中的 pin但缺失或过期的 pin 会以 note 形式回退到现场解析而不是失败——因此校验一个半更新的数据流永远不会比不带--locked构建它更严格。可复现性由build --locked强制而不是由validate强制。查看与更新 pin看什么被固定了dora hub list dataflow.yml列出锁文件中固定的每个 hub 包及其版本与短 commit二进制 pin 显示binary platform。没有锁文件时报错并指引你使用--write-lockfile。什么过期了dora hub outdated dataflow.yml把每个锁定的 pin 与索引中最新未被 yank的版本比较忽略 YAML 里的范围报告node: ns/name pinned - latest (newer available)。任何包无法检查时它以非零状态退出因此可以组合进 CI。应用更新dora hub update dataflow.yml # 重新解析 重写锁文件 dora hub update dataflow.yml --dry-run # 只显示会改什么不写任何东西update在 YAML 要求范围内重新解析每个节点并重写锁文件——但不编译任何东西。它产生的锁文件与dora build --write-lockfile逐字节一致它同样重新解析非 hub 的 git ref 并运行契约/类型检查只是省去了构建。审阅锁文件 diff 后提交它。outdated与update接受--offline只使用缓存的索引list只读本地锁文件无需网络。离线构建与源码镜像两个独立的机制用于处理网络受限或完全无网的环境--offline用于dora build、dora validate以及dora hub search/info/outdated/update跳过网络索引刷新只使用本地缓存缓存未命中时响亮地失败而不是静默走向过期。dora hub fetch把锁定的源码镜像到目录中——每个锁定 commit 的可校验本地副本供检查、审计、CI 源码缓存或手动转移到另一台机器dora hub fetch dataflow.yml # 镜像锁文件中的 pin dora hub fetch dataflow.yml --target-dir vendor # 镜像到 ./vendor dora hub fetch dora-yolo0.5.2 # 镜像单个包现场解析以数据流为目标时从锁文件读取 pin并像--locked一样对照当前 YAML 校验裸的nameversion则对索引现场解析。源码在其 pin 的 commit 处以 blobless-clone 方式放入dir/commit。尚不是开箱即用的完全断网构建。dora build仍然通过自己的构建缓存抓取 git 源目前不会复用这个镜像目录完全的断网源码复用是后续工作。今天fetch保证的是可校验的本地副本要在完全离线的构建中消费它需要手动操作。另外fetch只镜像git 源——二进制节点的制品由 daemon 在 spawn 时抓取并做 sha256 校验因此请把二进制节点url托管在目标机器可达的地方。推荐工作流用普通dora build开发在^/~范围内现场解析。分享或部署之前dora build --write-lockfile提交*.dora-lock.yaml。CI 与部署目标上dora build --locked索引缓存已预热时再加--offline。定期dora hub outdated然后dora hub update并审阅 diff。发布一个节点发布让节点可以用hub: namespace/nameversion安装。它不上传代码只是新增一条很小的、只追加的索引条目指向节点源码的某个 git commit。源码留在你的仓库里索引只记录“版本X的这个节点位于 commitY这是它的清单”。前置条件节点根目录有一个已提交的dora-node.yml含namespace与name。版本不是清单的一部分——它在被 pin 的 commit 处从[package].versionCargo/[project].versionpyproject读取或用--version提供在清单中加version:会被拒绝——解析器使用deny_unknown_fields。节点源码已推送到一个 git remote索引条目指向它。你的namespace匹配你控制的 GitHub 组织或用户见“命名空间与所有权”。预览条目cd my-node dora hub publish --dry-run这会解析 commit、以“已提交”的状态严格校验清单并打印它将要新增的精确namespace/name/version.yml索引条目——不写任何东西、不开 PR。先跑这个。实用参数Flag默认用途--rev refHEAD要 pin 的 git commit/ref--repo urloriginremote记录在条目中的源码仓库 URL--version semvercommit 处原生清单的版本覆盖发布版本--index alias绑定到你的命名空间的索引指定某个hub.toml索引--dry-run—校验 打印不写版本、名称与清单全部在被 pin 的 commit处读取通过git show commit:…而不是从你的工作树读取——因此未提交的清单或版本变更会报错而不会静默发布。先提交。发布到官方目录默认索引是dora-rs/dora-hub公共目录一个 git 仓库。由于它是 git 支撑的向它发布就是一次pull requestdora hub publish # 打印条目 针对 git 索引的 PR 指引针对 git 支撑的索引dora hub publish会打印条目以及如何开一个 PR 把它加到node-index/namespace/name/version.yml下的步骤。目录的 CI 随后校验条目schema、完整 commit pin、路径/命名空间一致性、只追加符合规范且由命名空间所有者提交的发布会自动合并——发布延迟就是 CI 延迟winget/conda-forge 模型。版本管理与 yank已发布的版本文件是不可变的——索引只追加。要发布新版本就发一个新条目要标记某个坏版本就yank它dora hub yank dora-yolo0.5.1 --reason panics on empty input dora hub yank dora-yolo0.5.1 --undo # 恢复它Yank 只是翻转条目上唯一一个可变的标志。yank.rs 的实现显示被 yank 的版本会被新的解析跳过所以^0.5会选下一个最高的好版本但已经把它 pin 住的锁文件仍然有效只是带一条警告——因此 yank 从不破坏已有的可复现构建只是阻止新构建选中它。与发布一样对 git 支撑的索引做 yank 就是一次小的 flag-flip PR对path 的本地索引则直接就地翻转。命名空间与所有权命名空间是一个 GitHub 组织或用户dora-rs、acme。索引键是namespace/name。一个命名空间只解析到一个索引没有搜索顺序因此没有依赖混淆。官方dora-rs命名空间始终解析到官方目录。每个包携带一份owners列表package.yml。目录的自动合并只适用于由该包命名空间所有者提交的常规发布新命名空间、owners 变更、或非所有者的 yank 会进入人工审核。新认领的命名空间还必须匹配认领作者的 GitHub 身份其登录名或其所属组织——认领别人的用户名会被拒绝。std命名空间与一个短保留列表dora、dora-rs、dora-hub、hub、official等是保留的。本地索引用于测试或磁盘上的私有目录时dora hub publish针对本地path 索引会直接追加条目原子操作拒绝覆盖已有版本而不是打印 PR 指引。配置方式见 自定义与企业索引。发布检查清单dora hub init # 脚手架 dora-node.yml如果还没有 dora validate --node-manifest dora-node.yml # 清单格式良好 # 提交 dora-node.yml 与版本变更push dora hub publish --dry-run # 预览精确条目 dora hub publish # 打印条目 PR 指引本地索引则直接追加自定义与企业索引默认情况下 Hub 从dora-rs/dora-hub公共目录解析每个命名空间。完全零配置时这就是唯一的索引。hub.toml让你添加私有或镜像目录并把命名空间绑定到它们——用于内部节点注册表、断网镜像或企业 fork。hub.toml配置位于~/.config/dora/hub.toml可用DORA_HUB_CONFIG环境变量覆盖路径。它是[[index]]条目的列表# 为 acme 命名空间服务的内部 git 支撑目录。 [[index]] alias acme git https://git.acme.internal/dora-index namespaces [acme, acme-labs] # 本地磁盘目录适合测试或断网环境。 [[index]] alias local path /srv/dora-index namespaces [sandbox]每个[[index]]的属性键含义alias必填唯一不区分大小写同时是缓存目录名git目录的 git remote URL ……path……或一个本地目录git clone 内的子路径默认是node-indexnamespaces该索引独占服务的命名空间从源码看libraries/hub-client/src/config.rs 的ResolvedConfig会强制校验这些规则alias 必须匹配[A-Za-z0-9_-]最长 64 字符因为它会成为缓存目录名git 索引的path必须是仓库内相对路径拒绝..、前导-、绝对路径每个条目必须有git或path之一。命名空间绑定杜绝依赖混淆解析不是搜索顺序——而是排他性映射这正是防止依赖混淆攻击的关键列在某个索引下的命名空间只在那里解析。任何未绑定到自定义索引的命名空间从官方目录解析。把同一命名空间绑定到两个索引是配置错误。官方dora-rs命名空间始终解析到官方目录自定义索引不能认领它。所以上例配置中hub: acme/lidar从acme索引解析而hub: dora-yolo仍从官方目录解析——每个包恰好只有一个来源。config.rs 的ResolvedConfig::new以bindings: BTreeMapString, usize实现这一映射其测试用例直接断言了“重复绑定报错”“非官方索引绑定dora-rs报错”“未绑定命名空间落到官方索引”。镜像官方索引把保留的officialalias 指向内部镜像就能连dora-rs命名空间也从你自己的基础设施解析[[index]] alias official git https://git.acme.internal/dora-hub-mirrorconfig.rs 中“official alias 可被覆盖”的测试用例验证了这一行为显式声明的official条目替换隐式默认其git即镜像地址。二进制分发已发布节点可以为某平台附带预编译二进制而不是要求每个消费者从源码编译——cargo-binstall 模型。索引条目的 source 增加一个binary列表source: binary: - platform: linux-x86_64 url: https://artifacts.acme.internal/lidar-2.1-linux-x86_64.tar.gz sha256: 64-hex fallback-git: # 可选没有二进制匹配时从源码构建 git: https://git.acme.internal/lidar rev: full-commit-hash subdir: nodes/lidar解析时如果条目为当前平台os-arch精确匹配附带二进制节点变成一个 sha256 校验的 URL 下载——不 clone、不构建否则若有fallback-git源节点从该源构建否则解析失败报清晰的“no binary for this platform”错误。制品url必须是https://下载后重新校验sha25664 位十六进制。二进制 pin 被记录进锁文件使--locked精确复现同一制品daemon在节点 spawn 时抓取并校验它对应 build/hub.rs 中BinaryPin的完整校验链https 强制的 URL、64 位十六进制 sha256、平台一致性、清单摘要一致性。dora hub fetch镜像 git 源但不镜像二进制制品。对于断网的二进制节点请把制品url托管到目标机器可达的地方。目录布局一个目录官方或你自己的是目录树node-index/ namespace/ name/ package.yml # 描述、仓库、owners version.yml # 每个已发布版本一条不可变条目每个version.yml持有节点清单原文外加其sourcegit pin 或二进制、published时间戳与yanked标志。目录只追加——对已发布版本唯一允许的变更就是yanked标志。新增条目见 发布一个节点。安全说明Hub 把索引条目视为不受信任的输入git 源 URL 在任何git子进程运行前做 scheme 校验https/ssh/file/git明文git://被拒绝。不受信任的索引条目不得指向本地路径除非设置DORA_HUB_ALLOW_LOCAL_SOURCES1。rev必须是完整的 40/64 位十六进制 commit——不允许分支、标签或缩写这些都是可变的。条目的namespace声明必须与它被抓取时的命名空间一致目录读写被限制在目录根内无符号链接逃逸。二进制制品下载后做 sha256 校验。在解析入口 build/hub.rs 中还能看到这些防线的落地git URL 会被normalize_git_source_url统一规范化scp 风格githost:path转为ssh://、绝对本地路径转为file://否则会与url::Url解析冲突索引条目声明namespace与请求命名空间不一致时直接报错“the index may have been tampered with”。与path:/git:的关系hub:是第四种节点来源与同一节点上的path:、git:和build:互斥。在底层Hub 会把hub:节点降级desugar成一条普通的、被 pin 的git:节点或一个经校验的二进制下载后才进入构建——因此你已知的关于 git 节点的所有知识仍然适用。Hub 的工作只是解析名称 版本 → commit 契约仅此而已。这一点在源码中体现得淋漓尽致resolve_hub_nodes对每个 hub 节点先做互斥字段检查path/git/build/branch/tag/rev/operator 字段任一存在即报错然后完成解析与契约注入最后把node.git、node.rev、node.path入口点与node.build填回描述符、清空node.hub使其变成下游协调器、daemon、锁文件眼中的普通 git 节点。结语Dora Hub 用一条hub:引用把 dora 节点的发现、复用、版本解析与类型校验统一进了dora build一条命令其“git 支撑索引 源码分发 锁文件可复现 端到端类型化”的设计让节点生态可以像 Cargo/npm 一样生长同时又对第三方索引、二进制分发与断网环境给出了明确的路径。对读者而言最实用的三条行动建议是消费节点前先dora hub info看清契约发布前用dora hub publish --dry-run预览条目CI/部署一律dora build --locked。本文对应的完整官方指南章节见 guide/src/hub/overview.md 及其五个子章节CLI 的十个子命令实现集中在 binaries/cli/src/command/hub解析与配置核心位于 libraries/hub-client/src可供深入阅读。【免费下载链接】doraDORA (Dataflow-Oriented Robotic Architecture) is middleware designed to streamline and simplify the creation of AI-based robotic applications. It offers low latency, composable, and distributed dataflow capabilities. Applications are modeled as directed graphs, also referred to as pipelines.项目地址: https://gitcode.com/GitHub_Trending/do/dora创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
