开发工具CLI机器学习【免费下载链接】huggingface_hubThe official CLI and Python client for the Hugging Face Hub.项目地址https://gitcode.com/gh_mirrors/hu/huggingface_hub点击查看免费下载本指南以 docs/source/en/guides/community.md 为核心脉络系统讲解huggingface_hub库如何通过HfApi类与hf discussions命令行工具检索、创建、编辑、合并模型/数据集/Space 仓库上的 Discussion讨论帖与 Pull Request拉取请求。读完本文你将能够用十余行 Python 代码完成社区讨论的全生命周期管理也能在 CI 流水线中零 Python 代码地用 CLI 完成同一套操作并深入理解这些接口背后与 Hub API 的对应关系。背景Hub 上的 Discussion 与 Pull RequestHugging Face Hub 上的每个仓库model / dataset / space都带有一个社区Community标签页其中承载两类协作对象Discussion讨论帖围绕仓库的公开话题如使用疑问、特性请求、数据质量反馈等Pull Request拉取请求PR针对仓库文件内容提出的、可合并的修改提案Hub 上的 PR 以refs/pr/编号这样的 git 引用存在底层是一套与 GitHub 类似的基于 git 的工作流。huggingface_hub以 Python 库 CLI 两种形态为这两类对象提供完整接口。所有相关数据模型定义在 community.py全部 HTTP 调用封装在 hf_api.pyCLI 子命令实现在 discussions.py。从 Hub 检索 Discussions 与 Pull Requests列出仓库的全部讨论与 PRHfApi类通过顶层函数get_repo_discussions暴露仓库级列表查询。最简单的用法直接迭代返回结果打印每个条目的编号、标题与类型 from huggingface_hub import get_repo_discussions for discussion in get_repo_discussions(repo_idbigscience/bloom): ... print(f{discussion.num} - {discussion.title}, pr: {discussion.is_pull_request}) # 11 - Add Flax weights, pr: True # 10 - Update README.md, pr: True # 9 - Training languages in the model card, pr: True # 8 - Update tokenizer_config.json, pr: True # 7 - Slurm training script, pr: False [...]每个返回对象是一个 [Discussion] 数据类见 community.py其字段包括字段说明title标题status状态取值为open、closed、merged仅 PR、draft仅 PRnum讨论/PR 编号repo_id仓库 id形如namespace/repo_namerepo_type仓库类型model、dataset、spaceauthor作者用户名若用户已被删除则显示为deletedis_pull_request是否为 Pull Requestcreated_at创建时间datetime对象git_reference属性若为 PR返回可推送变更的 git 引用refs/pr/num否则为Noneurl属性该讨论在 Hub 上的页面 URL按作者、类型与状态过滤get_repo_discussions支持三个过滤维度作者、类型PR 或 Discussion、状态open 或 closed from huggingface_hub import get_repo_discussions for discussion in get_repo_discussions( ... repo_idbigscience/bloom, ... authorArthurZ, ... discussion_typepull_request, ... discussion_statusopen, ... ): ... print(f{discussion.num} - {discussion.title} by {discussion.author}, pr: {discussion.is_pull_request}) # 19 - Add Flax weights by ArthurZ, pr: True从源码看hf_api.pydiscussion_type的合法取值为all、discussion、pull_requestdiscussion_status的合法取值为all、open、closed它们分别由 constants.py 中的DiscussionTypeFilter与DiscussionStatusFilter类型别名约束。这些参数会原样拼入 GET 请求的 query 参数type、status、authorHub API 不接受列表接口上的merged/draft状态过滤——这也是下文 CLI 实现中把这两种状态改为客户端过滤的原因。分页与批量收集get_repo_discussions返回的是一个Python 生成器generator而不是完整列表。其底层实现hf_api.py按页拉取 Hub API 的.../discussions分页结果每次请求携带p页码参数通过响应中的count、start与当前页discussions列表长度判断是否还有下一页。这样处理的好处是对于拥有成百上千条讨论的仓库可以边取边消费不会一次性把全部数据加载进内存。如果需要一次性拿到全部数据用list()包裹即可 from huggingface_hub import get_repo_discussions discussions_list list(get_repo_discussions(repo_idbert-base-uncased))仓库测试同样覆盖了这一用法见 test_hf_api.py包括按discussion_type、discussion_status、author过滤以及对 Space 仓库repo_typespace的查询。获取单个 Discussion / PR 的详细信息列表接口返回的是概览级信息。要查看一条讨论/PR 的完整上下文使用get_discussion_details它以仓库 id 讨论编号为入参 from huggingface_hub import get_discussion_details get_discussion_details( ... repo_idbigscience/bloom-1b3, ... discussion_num2 ... ) DiscussionWithDetails( num2, authorcakiki, titleUpdate VRAM memory for the V100s, statusopen, is_pull_requestTrue, events[ DiscussionComment(typecomment, authorcakiki, ...), DiscussionCommit(typecommit, authorcakiki, summaryUpdate VRAM memory for the V100s, oid1256f9d9a33fa8887e1c1bf0e09b4713da96773a, ...), ], conflicting_files[], target_branchrefs/heads/main, merge_commit_oidNone, diffdiff --git a/README.md b/README.md\nindex a6ae3b9294edf8d0eda0d67c7780a10241242a7e..3a1814f212bc3f0d3cc8f74bdbd316de4ae7b9e3 100644\n--- a/README.md\n b/README.md\n -132,7 132,7 [...], )DiscussionWithDetails是Discussion的子类community.py额外携带以下字段events讨论/PR 的全部事件序列包括所有评论DiscussionComment、状态变更DiscussionStatusChange、提交DiscussionCommit与标题修改DiscussionTitleChange。源码中deserialize_eventcommunity.py根据事件type字段把原始 JSON 分派为上述四个具体类未识别的事件则退化为基类DiscussionEventconflicting_files仅 PR 有值。为冲突文件列表True表示存在冲突但列表无法获取非 PR 时为Nonetarget_branch仅 PR 有值指出变更要合并进的目标分支如refs/heads/mainmerge_commit_oid已合并 PR 的合并提交 OID/SHA否则为Nonediff仅 PR 有值为原始 git diff 文本。从实现看hf_api.py该接口的 HTTP 请求在discussion_num非正整数时直接抛出ValueError请求携带params{diff: 1}以要求 Hub 返回 diff随后将filesWithConflicts、changes.base、changes.mergeCommitId分别映射到上述字段。测试用例 test_hf_api.py 验证了同时检索 Discussion 与 PR 细节的完整路径。值得注意的是DiscussionComment还额外提供renderedHTML 渲染结果、last_edited_at、last_edited_by、edit_history、number_of_edits等便捷属性community.py可用于实现评论审计类工具。以编程方式创建与编辑 Discussion / PR创建与编辑操作需要访问令牌access token。所有写操作都会自动使用本地缓存的令牌~/.cache/huggingface/token也可以通过token你的访问令牌参数显式传入。方式一通过create_commit一键发起 PR最简单的提交换形式是使用create_commit把create_pr参数设为TrueHub 会为你自动创建一条包含本次变更的 Pull Request。该参数同样在以下包装方法上可用upload_fileupload_folderdelete_filedelete_foldermetadata_update例如用metadata_update修改模型卡元数据并以 PR 形式提交 from huggingface_hub import metadata_update metadata_update( ... repo_idusername/repo_name, ... metadata{tags: [computer-vision, awesome-model]}, ... create_prTrue, ... )这一路径适合一次提交即成 PR的场景——变更内容与 PR 创建在同一次 API 调用中完成无需先建 PR 再推送分支。方式二先建 Discussion / PR 再迭代修改如果需要先在本地准备工作内容或需要一个独立的空 PR 作为协作容器可以使用create_discussion讨论与create_pull_requestPR from huggingface_hub import create_discussion, create_pull_request create_discussion( ... repo_idusername/repo-name, ... titleHi from the huggingface_hub library!, ... tokeninsert your access token here, ... ) DiscussionWithDetails(...) create_pull_request( ... repo_idusername/repo-name, ... titleHi from the huggingface_hub library!, ... tokeninsert your access token here, ... ) DiscussionWithDetails(..., is_pull_requestTrue)从实现看hf_api.pycreate_pull_request本质上是create_discussion的薄封装——仅把pull_requestTrue传入create_discussion。二者的注意点以编程方式创建的 PR 处于draft模式即草稿状态需手动转为可合并状态可借助后述change_discussion_status之外的方式在 Hub 界面完成title长度要求为 3200 字符首尾空白会被剔除description缺省时自动填充Pull Request opened with the huggingface_hub Python library或对应 Discussion 文案创建成功后立即回查get_discussion_details返回完整详情对象。通过HfApi完成全套管理操作Discussion 与 PR 的日常管理可以完全交给HfApi常用方法与职责对应如下方法作用comment_discussion添加评论支持 Markdown 格式源码示例见 hf_api.pyedit_discussion_comment编辑指定评论需要评论 id可从get_discussion_details的 events 中获得rename_discussion重命名 Discussion 或 PRchange_discussion_status打开或关闭 Discussion / PRnew_status仅接受open或closed源码在 hf_api.py 中会校验并抛出ValueErrormerge_pull_request合并一个 PR评论与状态变更等写操作在底层都收敛到_post_discussion_changes这一个内部工具方法hf_api.py统一 POST 到.../discussions/编号/resource端点comment、title、status、merge并复用同一套参数校验逻辑。HfApi文档页提供以上所有方法的完整参考。从命令行管理 Discussions 与 PR上述全部操作都能通过hf discussions子命令在终端完成——适合脚本化、CI 流水线或不想写 Python 代码的快速交互场景。该子命令的完整实现位于 discussions.py并在 hf.py 中注册进hf命令组。常用命令一览# 列出仓库中开放的讨论与 PR hf discussions list bigscience/bloom # 列出数据集仓库上的讨论 hf discussions list nebius/SWE-rebench-V2 --type dataset # 查看某条讨论的详细信息含评论线程 hf discussions info bigscience/bloom 2 # 新建一条讨论 hf discussions create username/repo-name --title Bug report --body Description here # 新建一个 Pull Request hf discussions create username/repo-name --title Fix typo --pull-request # 在讨论或 PR 下评论 hf discussions comment username/repo-name 5 --body LGTM! # 合并一个 Pull Request hf discussions merge username/repo-name 5 --yes # 查看一个 PR 的 diff hf discussions diff username/repo-name 5各子命令的完整参数CLI 层的参数设计直接映射到HfApi方法以下基于 discussions.py 的实现逐条展开hf discussions list repo_id列出仓库的讨论与 PR默认展示前 30 条并以表格输出列为num、title、is_pull_request、status、author、created_at。支持过滤选项-s, --statusopen默认、closed、merged、draft、all-k, --kinddiscussion、pull_request、all默认--author按作者过滤--limit输出条数上限默认 30--type仓库类型model默认、dataset、space--token指定访问令牌--format json等输出格式选项。一个值得注意的实现细节discussions.pyHub 列表 API 的状态过滤只接受all/open/closed因此当用户请求merged或draft时CLI 会先以全部拉取再在客户端侧按d.status status.value过滤discussions.py。hf discussions info repo_id num获取单条讨论/PR 的详情内部调用api.get_discussion_details并以字典形式输出JSON 模式下包含完整 events 线程。hf discussions create repo_id创建讨论或 PR。必填--title可选--bodyMarkdown 描述与--body-file从文件读取描述传-表示从标准输入读取--pull-request/--pr把类型切换为 PR。若同时传入--body与--body-file会抛出参数错误discussions.py。创建成功后输出编号与 URLPR 场景还会给出refs/pr/num引用。hf discussions comment repo_id num发表评论--body或--body-file二选一都未提供时报错。hf discussions edit repo_id num comment_id编辑指定评论。comment_id可通过hf discussions info ... --format json从事件线程中取得。hf discussions close / reopen repo_id num关闭/重新打开讨论或 PR均有确认提示可用-y/--yes跳过确认可加--comment附注说明。hf discussions rename repo_id num new title重命名讨论或 PR。hf discussions merge repo_id num合并 PR同样支持--yes跳过确认与--comment附注。hf discussions diff repo_id num输出指定 PR 的原始 git diff若 PR 无 diff 则打印No diff available.。hf discussions --help可查看全部选项的完整列表CLI 参考文档见 CLI 参考。这些命令在仓库测试 test_cli_discussions.py 中有端到端覆盖包括创建、评论、评论文件输入、关闭/重开、重命名等场景。将变更推送到已有 Pull Request官方文档目前将向已有 PR 推送变更即通过refs/pr/num引用把本地提交推上去标记为Coming soon敬请期待。就当前仓库的实现而言Discussion.git_reference属性community.py已经为每个 PR 生成了形如refs/pr/num的引用这是未来推送能力的落点create_pull_request文档字符串也明确指出带变更一次性创建 PR 可改用HfApi.create_commithf_api.py——因此现阶段若需向 PR 补充内容推荐做法是先用create_commit(create_prTrue)直接生成带变更的 PR。实战小结围绕 Hub 的社区协作可以沉淀出如下工作流巡检get_repo_discussionsPython或hf discussions listCLI按状态、类型、作者过滤出待办清单深入get_discussion_details/hf discussions info查看完整事件线程、冲突文件、目标分支与 git diff提案小改动直接用create_commit(create_prTrue)一行生成 PR大改动先用create_pull_request建草稿 PR 再本地准备内容协作comment_discussion、rename_discussion、change_discussion_status完成评论、改名、开关生命周期落地评审通过后merge_pull_request/hf discussions merge合入目标分支。每一步都可以在 Python 与 CLI 之间无缝切换全部底层行为与 Hub 的.../discussionsREST 端点一一对应数据模型清晰稳定非常适合嵌入数据治理、模型卡审核、批量提交流水线等自动化场景。延伸阅读数据模型与事件结构定义community.py全部 API 方法与参数细节hf_api.pyCLI 子命令实现与测试discussions.py、test_cli_discussions.py类型约束常量constants.py赞分享开发工具CLI机器学习【免费下载链接】huggingface_hubThe official CLI and Python client for the Hugging Face Hub.项目地址https://gitcode.com/gh_mirrors/hu/huggingface_hub点击查看免费下载相关推荐3 步保存任意在线流媒体免费流媒体下载器 N_m3u8DL-RE 零基础实操手册3 步保存任意在线流媒体免费流媒体下载器 N_m3u8DL RE 零基础实操手册 想把某平台上的课程视频完整保存下来播放器里却只有一串 m3u8 或 mpd开发工具CLI机器学习使用 huggingface_hub 与 Hub 上的 Discussions 和 Pull Requests 交互API 方法、数据模型与 CLI 实战使用 huggingface_hub 与 Hub 上的 Discussions 和 Pull Requests 交互API 方法、数据模型与 CLI 实战 本开发工具CLI机器学习huggingface_hub 与 Hub 社区互动实战用 Python API 与 CLI 全流程管理讨论和拉取请求Pull Requesthuggingface_hub 与 Hub 社区互动实战用 Python API 与 CLI 全流程管理讨论和拉取请求Pull Request 本文以 h开发工具CLI机器学习上一篇如何把 IDM 的 30 天试用期冻结终身IDM激活脚本完整使用指南下一篇Dify 工作流完整教程5 分钟导入并跑通你的第一个流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考