尧图网页设计 
mem0-cli Python 包工程实践Ruff/Pytest/Hatch 规范与 CI 发布管线解析【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain本文基于 mem0 仓库中cli/python/目录的工程规范文档CLAUDE.md完整还原 Python 官方 CLI 包mem0-cli的开发命令、代码风格约定、包结构与依赖策略并结合 pyproject.toml、Makefile 和 GitHub Actions 工作流源码逐条印证。读完本文你将掌握在该目录下进行 lint、测试、构建的正确姿势理解“为什么这里行宽是 100 而不是 120”这类容易踩坑的细节以及从打 tag 到发布 PyPI 的完整自动化链路。1. 包定位mem0-cli 是什么mem0-cli是 mem0 官方 Python CLI发布在 PyPI 上基于Typer构建命令行入口名为mem0。它在 pyproject.toml 中声明为[project] name mem0-cli version 0.2.12 description The official CLI for mem0 — the memory layer for AI agents requires-python 3.10规范文档CLAUDE.md将其结构概括为标准的src layoutcli/python/ ├── src/mem0_cli/ package source (src layout) └── tests/入口点在 pyproject.toml 的[project.scripts]中登记为mem0 mem0_cli.app:main与文档声明完全一致。追踪到源码可以确认这条调用链src/mem0_cli/app.py 中的main()是真正的可调用入口。它在启动时扫描sys.argv若发现--json/--agent全局标记允许出现在命令行任意位置而不必在子命令之前会先调用set_agent_mode(True)进入面向 LLM Agent 的 JSON 输出模式然后过滤掉这些标记再交给 Typer 应用app()执行顶层app是一个typer.Typer(namemem0, ...)实例app.py#L23-L32注册了add、search、get、list、update、delete、config、entity、event、init等命令组--json标记下可输出机器可读的 help 供 Agent 消费mem0 help --json后端抽象位于 src/mem0_cli/backend/base.py定义抽象类Backend和工厂函数get_backend(config)当前实现为PlatformBackendplatform.py。因此理解这个包的工程约定前提是认识到它是一个独立于根 SDK 的、面向终端用户和 AI Agent 的发行包而不是根目录mem0/Python SDK 的一部分。2. 开发命令速查规范文档给出的核心工作流是五条命令CLAUDE.md#L5-L13pip install -e .[dev] # 开发安装附带 ruff pytest ruff check . # lint ruff format . # 格式化 pytest # 测试 hatch build # 构建其中[dev]extra 在 pyproject.toml 中的完整内容为[project.optional-dependencies] dev [ pytest7.0, pytest-asyncio0.21, ruff0.1.0, ]除了裸命令仓库还提供了一个 Makefile把所有操作封装进带虚拟环境管理的 target 中适合日常使用Make target实际执行说明make devpip install -e .[dev]在.venv中做开发安装make lintruff check .ruff format --check .检查 格式校验不改动文件make formatruff check --fix .ruff format .自动修复并格式化make testpytest运行tests/下的全部测试make buildhatch build先clean删除dist/再构建make publish/make publish-testhatch publish [--repo test]手动发布正式发布走 CD 工作流见第 5 节注意make lint使用ruff format --check而非ruff format这与 CI 中“只校验、不自动改写”的行为保持一致而make format才会实际改写文件。3. 代码风格约定行宽 100 是硬规则规范文档中最醒目的警告是CLAUDE.md#L15-L19本目录行宽是 100不是 120。根 Python SDK 使用 120。如果在cli/python/上运行根目录的make format会重排所有文件并导致 CI 失败。请使用本目录的本地ruff命令。这一点在两份配置文件中可以得到精确印证本目录 pyproject.toml[tool.ruff]下target-version py310、line-length 100仓库根 pyproject.toml根 SDK 的line-length 120。两个包各自声明了独立的[tool.ruff]段ruff 会就近读取cli/python/pyproject.toml所以从cli/python/目录运行ruff check ./ruff format .时生效的是 100 行宽而根目录的格式化脚本带着 120 的配置进来就会把整个目录重排——这正是文档警告的 CI 失败场景。完整的 ruff 规则集同样在 pyproject.toml#L54-L77 中声明与文档描述逐条对应[tool.ruff.lint] select [ E, # pycodestyle errors F, # pyflakes I, # isort (import 排序) W, # pycodestyle warnings UP, # pyupgrade (现代 Python 语法) B, # flake8-bugbear (常见 bug) SIM, # flake8-simplify RUF, # ruff 专属规则 ] ignore [ E501, # 行过长 —— 由 formatter 处理 B008, # 默认参数中的函数调用 —— Typer 的 Option/Argument 模式所必需 SIM108, # 三元表达式 —— 有时可读性更差 ] [tool.ruff.lint.isort] known-first-party [mem0_cli] [tool.ruff.format] quote-style double indent-style space docstring-code-format true其中两条 ignore 规则值得注意它们都是 Typer 框架特性与 lint 规则冲突的产物B008Typer 的参数默认值惯用写法是typer.Option(None, --user-id, ...)即“在默认参数位置调用函数”这天然触发 flake8-bugbear 的 B008。可以推断这正是 app.py 中大量typer.Option(...)/typer.Argument(...)写法能全部通过 lint 的原因E501行宽检查整体关闭交给ruff format处理避免 formatter 与 linter 对行宽产生双重约束。其余约定与文档一一对应Python 3.10requires-python 3.10明确“不是 3.9与根 SDK 不同”target-version py310使UPpyupgrade规则按 3.10 语法升级代码isort 一级模块known-first-party [mem0_cli]即只有mem0_cli被识别为 first-partymem0ai、typer等一律按第三方排序测试框架pytest含pytest-asyncio说明测试中使用了异步用例。4. 依赖策略硬依赖最小化mem0ai 保持可选规范文档CLAUDE.md#L40-L42对依赖的表述是Typer Rich httpx。mem0ai是可选依赖通过[oss]extra 暴露用于 OSS 模式。不要把它提升为必选依赖。pyproject.toml#L27-L34 中的实际声明与之一致dependencies [ typer0.9.0, rich13.0.0, httpx0.24.0, ] [project.optional-dependencies] oss [mem0ai0.1.0]从源码结构看当前src/mem0_cli/中的实现没有直接import mem0ai后端工厂get_backendbase.py#L127目前落地的是PlatformBackend一条路径mem0ai根目录的同名 Python SDK被保留为[oss]可选依赖意味着安装pip install mem0-cli时不会拖入完整的 OSS 记忆栈只有显式pip install mem0-cli[oss]才会带上它。这种“核心依赖 typer rich httpx 三件套OSS 能力走 extra”的切分是保持 CLI 安装轻量、且不与根 SDK 版本强耦合的关键设计文档特别强调“不要提升为必选依赖”就是在防止后续重构时打破这一边界。三个硬依赖的分工在源码中也可以看到对应关系typer命令与参数解析app.pyrich终端渲染Console、err_console以及品牌色输出app.py#L13-L19httpxPlatform 后端的 HTTP 通信PlatformBackend内部使用。5. CI 与发布tag 前缀 cli-v* 驱动的 PyPI 流水线规范文档最后给出 CI/CD 的两句结论CLAUDE.md#L44-L47两份工作流文件提供了完整细节。5.1 CIlint 三版本矩阵测试 构建校验.github/workflows/cli-python-ci.yml 定义三个 joblintPython 3.12pip install -e .[dev]后依次执行ruff check .与ruff format --check .test矩阵3.10/3.11/3.12在三个 Python 版本上各跑一次pytest——这正是requires-python 3.10支持范围的直接验证buildPython 3.12pip install hatch后执行hatch build --clean并额外校验dist/下同时存在.whl和.tar.gz任一缺失即失败。工作流头部注释还说明了一个细节PR 场景下它由ci-gate.yml以workflow_call方式被调用作为唯一的必需检查项而 push 到main和手动触发则独立运行触发路径限定为cli/python/**与工作流文件自身因此修改cli/python/之外的代码不会拉起这条流水线。5.2 CDcli-v* tag 经 OIDC 发布到 PyPI.github/workflows/cli-python-cd.yml 是发布侧关键事实触发方式由release.ymlRelease Router在检测到cli-v*前缀的 release tag 时以workflow_dispatch派发inputs.tag例如cli-v0.2.0工作流内还有兜底守卫if: startsWith(inputs.tag, cli-v)手动补发时同样必须传cli-v*前缀的 tag。这与文档“tag 前缀cli-v*触发cli-python-cd.yml”的描述一致也解释了为什么这个包与根 SDK 的发布 tag 互不干扰权限permissions: id-token: write配合pypa/gh-action-pypi-publishrelease/v1通过OIDC 换取 PyPI Trusted Publishing 令牌完成发布全程无需在 Secrets 中存放长期 API token构建检出指定 tag 的代码在 Python 3.11 上pip install hatch后hatch build --clean产物目录cli/python/dist/直接作为发布包来源。6. 小结贡献该目录前的检查清单综合 CLAUDE.md、pyproject.toml 与两份工作流对cli/python/做改动时以下约束是可直接执行的验收标准Python 版本代码需兼容 3.10CI 矩阵是 3.10/3.11/3.12不要引入仅 3.9 可用或仅 3.13 才有的语法假设格式在cli/python/内运行ruff check .与ruff format .行宽 100、双引号、空格缩进切勿使用根目录的make format测试pytest全绿后才可提交CI 会按三个 Python 版本各跑一遍依赖新增运行时依赖需谨慎——mem0ai必须留在[oss]extra 中不得进入dependencies构建hatch build需能同时产出 wheel 与 sdist发布由cli-v*tag 自动经 OIDC 推送到 PyPI本地make publish不作为常规路径。以上每一条都能在 cli/python/ 目录内的配置与工作流文件中找到对应证据可按路径继续深入核对。【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 mem0-cli Python 包工程实践：Ruff/Pytest/Hatch 规范与 CI 发布管线解析
mem0-cli Python 包工程实践Ruff/Pytest/Hatch 规范与 CI 发布管线解析【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain本文基于 mem0 仓库中cli/python/目录的工程规范文档CLAUDE.md完整还原 Python 官方 CLI 包mem0-cli的开发命令、代码风格约定、包结构与依赖策略并结合 pyproject.toml、Makefile 和 GitHub Actions 工作流源码逐条印证。读完本文你将掌握在该目录下进行 lint、测试、构建的正确姿势理解“为什么这里行宽是 100 而不是 120”这类容易踩坑的细节以及从打 tag 到发布 PyPI 的完整自动化链路。1. 包定位mem0-cli 是什么mem0-cli是 mem0 官方 Python CLI发布在 PyPI 上基于Typer构建命令行入口名为mem0。它在 pyproject.toml 中声明为[project] name mem0-cli version 0.2.12 description The official CLI for mem0 — the memory layer for AI agents requires-python 3.10规范文档CLAUDE.md将其结构概括为标准的src layoutcli/python/ ├── src/mem0_cli/ package source (src layout) └── tests/入口点在 pyproject.toml 的[project.scripts]中登记为mem0 mem0_cli.app:main与文档声明完全一致。追踪到源码可以确认这条调用链src/mem0_cli/app.py 中的main()是真正的可调用入口。它在启动时扫描sys.argv若发现--json/--agent全局标记允许出现在命令行任意位置而不必在子命令之前会先调用set_agent_mode(True)进入面向 LLM Agent 的 JSON 输出模式然后过滤掉这些标记再交给 Typer 应用app()执行顶层app是一个typer.Typer(namemem0, ...)实例app.py#L23-L32注册了add、search、get、list、update、delete、config、entity、event、init等命令组--json标记下可输出机器可读的 help 供 Agent 消费mem0 help --json后端抽象位于 src/mem0_cli/backend/base.py定义抽象类Backend和工厂函数get_backend(config)当前实现为PlatformBackendplatform.py。因此理解这个包的工程约定前提是认识到它是一个独立于根 SDK 的、面向终端用户和 AI Agent 的发行包而不是根目录mem0/Python SDK 的一部分。2. 开发命令速查规范文档给出的核心工作流是五条命令CLAUDE.md#L5-L13pip install -e .[dev] # 开发安装附带 ruff pytest ruff check . # lint ruff format . # 格式化 pytest # 测试 hatch build # 构建其中[dev]extra 在 pyproject.toml 中的完整内容为[project.optional-dependencies] dev [ pytest7.0, pytest-asyncio0.21, ruff0.1.0, ]除了裸命令仓库还提供了一个 Makefile把所有操作封装进带虚拟环境管理的 target 中适合日常使用Make target实际执行说明make devpip install -e .[dev]在.venv中做开发安装make lintruff check .ruff format --check .检查 格式校验不改动文件make formatruff check --fix .ruff format .自动修复并格式化make testpytest运行tests/下的全部测试make buildhatch build先clean删除dist/再构建make publish/make publish-testhatch publish [--repo test]手动发布正式发布走 CD 工作流见第 5 节注意make lint使用ruff format --check而非ruff format这与 CI 中“只校验、不自动改写”的行为保持一致而make format才会实际改写文件。3. 代码风格约定行宽 100 是硬规则规范文档中最醒目的警告是CLAUDE.md#L15-L19本目录行宽是 100不是 120。根 Python SDK 使用 120。如果在cli/python/上运行根目录的make format会重排所有文件并导致 CI 失败。请使用本目录的本地ruff命令。这一点在两份配置文件中可以得到精确印证本目录 pyproject.toml[tool.ruff]下target-version py310、line-length 100仓库根 pyproject.toml根 SDK 的line-length 120。两个包各自声明了独立的[tool.ruff]段ruff 会就近读取cli/python/pyproject.toml所以从cli/python/目录运行ruff check ./ruff format .时生效的是 100 行宽而根目录的格式化脚本带着 120 的配置进来就会把整个目录重排——这正是文档警告的 CI 失败场景。完整的 ruff 规则集同样在 pyproject.toml#L54-L77 中声明与文档描述逐条对应[tool.ruff.lint] select [ E, # pycodestyle errors F, # pyflakes I, # isort (import 排序) W, # pycodestyle warnings UP, # pyupgrade (现代 Python 语法) B, # flake8-bugbear (常见 bug) SIM, # flake8-simplify RUF, # ruff 专属规则 ] ignore [ E501, # 行过长 —— 由 formatter 处理 B008, # 默认参数中的函数调用 —— Typer 的 Option/Argument 模式所必需 SIM108, # 三元表达式 —— 有时可读性更差 ] [tool.ruff.lint.isort] known-first-party [mem0_cli] [tool.ruff.format] quote-style double indent-style space docstring-code-format true其中两条 ignore 规则值得注意它们都是 Typer 框架特性与 lint 规则冲突的产物B008Typer 的参数默认值惯用写法是typer.Option(None, --user-id, ...)即“在默认参数位置调用函数”这天然触发 flake8-bugbear 的 B008。可以推断这正是 app.py 中大量typer.Option(...)/typer.Argument(...)写法能全部通过 lint 的原因E501行宽检查整体关闭交给ruff format处理避免 formatter 与 linter 对行宽产生双重约束。其余约定与文档一一对应Python 3.10requires-python 3.10明确“不是 3.9与根 SDK 不同”target-version py310使UPpyupgrade规则按 3.10 语法升级代码isort 一级模块known-first-party [mem0_cli]即只有mem0_cli被识别为 first-partymem0ai、typer等一律按第三方排序测试框架pytest含pytest-asyncio说明测试中使用了异步用例。4. 依赖策略硬依赖最小化mem0ai 保持可选规范文档CLAUDE.md#L40-L42对依赖的表述是Typer Rich httpx。mem0ai是可选依赖通过[oss]extra 暴露用于 OSS 模式。不要把它提升为必选依赖。pyproject.toml#L27-L34 中的实际声明与之一致dependencies [ typer0.9.0, rich13.0.0, httpx0.24.0, ] [project.optional-dependencies] oss [mem0ai0.1.0]从源码结构看当前src/mem0_cli/中的实现没有直接import mem0ai后端工厂get_backendbase.py#L127目前落地的是PlatformBackend一条路径mem0ai根目录的同名 Python SDK被保留为[oss]可选依赖意味着安装pip install mem0-cli时不会拖入完整的 OSS 记忆栈只有显式pip install mem0-cli[oss]才会带上它。这种“核心依赖 typer rich httpx 三件套OSS 能力走 extra”的切分是保持 CLI 安装轻量、且不与根 SDK 版本强耦合的关键设计文档特别强调“不要提升为必选依赖”就是在防止后续重构时打破这一边界。三个硬依赖的分工在源码中也可以看到对应关系typer命令与参数解析app.pyrich终端渲染Console、err_console以及品牌色输出app.py#L13-L19httpxPlatform 后端的 HTTP 通信PlatformBackend内部使用。5. CI 与发布tag 前缀 cli-v* 驱动的 PyPI 流水线规范文档最后给出 CI/CD 的两句结论CLAUDE.md#L44-L47两份工作流文件提供了完整细节。5.1 CIlint 三版本矩阵测试 构建校验.github/workflows/cli-python-ci.yml 定义三个 joblintPython 3.12pip install -e .[dev]后依次执行ruff check .与ruff format --check .test矩阵3.10/3.11/3.12在三个 Python 版本上各跑一次pytest——这正是requires-python 3.10支持范围的直接验证buildPython 3.12pip install hatch后执行hatch build --clean并额外校验dist/下同时存在.whl和.tar.gz任一缺失即失败。工作流头部注释还说明了一个细节PR 场景下它由ci-gate.yml以workflow_call方式被调用作为唯一的必需检查项而 push 到main和手动触发则独立运行触发路径限定为cli/python/**与工作流文件自身因此修改cli/python/之外的代码不会拉起这条流水线。5.2 CDcli-v* tag 经 OIDC 发布到 PyPI.github/workflows/cli-python-cd.yml 是发布侧关键事实触发方式由release.ymlRelease Router在检测到cli-v*前缀的 release tag 时以workflow_dispatch派发inputs.tag例如cli-v0.2.0工作流内还有兜底守卫if: startsWith(inputs.tag, cli-v)手动补发时同样必须传cli-v*前缀的 tag。这与文档“tag 前缀cli-v*触发cli-python-cd.yml”的描述一致也解释了为什么这个包与根 SDK 的发布 tag 互不干扰权限permissions: id-token: write配合pypa/gh-action-pypi-publishrelease/v1通过OIDC 换取 PyPI Trusted Publishing 令牌完成发布全程无需在 Secrets 中存放长期 API token构建检出指定 tag 的代码在 Python 3.11 上pip install hatch后hatch build --clean产物目录cli/python/dist/直接作为发布包来源。6. 小结贡献该目录前的检查清单综合 CLAUDE.md、pyproject.toml 与两份工作流对cli/python/做改动时以下约束是可直接执行的验收标准Python 版本代码需兼容 3.10CI 矩阵是 3.10/3.11/3.12不要引入仅 3.9 可用或仅 3.13 才有的语法假设格式在cli/python/内运行ruff check .与ruff format .行宽 100、双引号、空格缩进切勿使用根目录的make format测试pytest全绿后才可提交CI 会按三个 Python 版本各跑一遍依赖新增运行时依赖需谨慎——mem0ai必须留在[oss]extra 中不得进入dependencies构建hatch build需能同时产出 wheel 与 sdist发布由cli-v*tag 自动经 OIDC 推送到 PyPI本地make publish不作为常规路径。以上每一条都能在 cli/python/ 目录内的配置与工作流文件中找到对应证据可按路径继续深入核对。【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考