ModelScope 开发指南代码规范、分级测试、协作流程与 pip 打包全解析【免费下载链接】modelscopeModelScope: bring the notion of Model-as-a-Service to life.项目地址: https://gitcode.com/GitHub_Trending/mo/modelscopeModelScopeModel-as-a-Service 开源框架面向贡献者提供的官方开发文档覆盖从代码风格约束、分级测试体系、测试数据管理到分支协作与 pip 打包的完整研发链路。本文以仓库内 docs/source/develop_cn.md 为核心骨架结合仓库内的 Makefile、setup.cfg、.pre-commit-config.yaml、modelscope/utils/test_utils.py 等源码与配置文件逐项展开帮助你掌握 ModelScope 贡献代码、编写测试、通过 CI 审查并产出 pip 安装包的完整工作流。1. 代码风格PEP8 与自动化检查工具链ModelScope 以 PEP8 作为首选代码风格并引入三件套工具保证风格落地工具职责flake8语法检查器linter发现未使用导入、未定义名称、行超长等静态问题yapf代码格式化工具按配置自动重排代码isort导入import语句排序工具这三个工具的样式配置统一收敛在仓库根目录的 setup.cfg 中具体如下[isort]段line_length 79限制导入行宽known_first_party modelscope将modelscope识别为一等包first-party保证框架内部导入与其他第三方库分开排序[yapf]段BASED_ON_STYLE pep8声明基于 PEP8 的格式化基准并启用嵌套类/函数前空行、开括号后表达式换行、算术运算符前置换行等细节[flake8]段max-line-length 120代码行上限 120比 isort 的导入行更宽松select B,C,E,F,P,T4,W,B9与ignore F401,F403,F405,F821,W503,E251明确了启用与豁免的检查项例如忽略未使用导入F401与行尾运算符换行W503。1.1 安装并初始化 pre-commit 钩子仓库使用 pre-commit 在每次 git commit 时自动执行flake8、yapf、seed-isort-config、isort、trailing whitespaces 检查并自动修复 end-of-files、对requirements.txt排序。钩子配置见 .pre-commit-config.yaml其中明确了各 hook 的版本如 yapf 固定为 v0.30.0以及需要排除的文件如examples/、thirdparty/等目录下的代码不做强制格式化。克隆仓库后需要先安装依赖并初始化钩子# 安装测试与开发依赖flake8、isort、pre-commit、yapf 等 pip install -r requirements/tests.txtrequirements/tests.txt 中除上述工具外还固定了yapf0.30.0其注释明确指出使用固定版本以保证自动格式化风格一致。然后在仓库根目录初始化钩子pre-commit install此后每次提交代码检查与格式化工具都会自动生效。如需对所有文件执行一遍检查例如首次接入时运行pre-commit run --all-files如果只想手动触发格式化和检查而不走 git 钩子可以直接使用 Makefile 中的 linter 目标见 Makefilemake linter其底层执行的是.dev_scripts/linter.sh脚本。2. 测试体系三级分层与 TEST_LEVEL 环境变量2.1 三个测试级别ModelScope 将测试划分为三个级别分别对应不同的验证范围与运行成本级别定位典型示例级别 0框架基础接口与功能测试核心单测tests/trainers/下的 trainer 基础用例如test_trainer.py级别 1重要功能测试验证端到端工作流tests/pipelines/test_image_matting.py图像抠图 pipeline 全流程级别 2各算法领域模型、pipeline 等所有实现模块的场景测试各领域覆盖度最广的测试用例默认测试级别为 0即默认只运行级别 0 的用例级别通过环境变量TEST_LEVEL设置# 运行所有测试级别 0/1/2 TEST_LEVEL2 make test # 运行重要功能测试级别 0/1 TEST_LEVEL1 make test # 运行核心单元测试和基本功能测试仅级别 0 make testmake test底层调用的是.dev_scripts/citest.sh脚本见 Makefile。2.2 测试级别的源码实现测试级别的判定逻辑位于 modelscope/utils/test_utils.pyTEST_LEVEL 2 TEST_LEVEL_STR TEST_LEVEL def test_level(): global TEST_LEVEL if TEST_LEVEL_STR in os.environ: TEST_LEVEL int(os.environ[TEST_LEVEL_STR]) return TEST_LEVEL可见模块内部默认TEST_LEVEL 2但只要环境中存在TEST_LEVEL变量就会以环境变量覆盖模块默认值。这也是文档特别提醒如果单测无法运行请检查环境变量 TEST_LEVEL 是否存在若存在请取消设置的原因——残留的TEST_LEVEL2会让测试运行器尝试执行全部级别的用例导致本应只跑级别 0 的本地开发测试因需要下载模型/数据集而失败或变慢。2.3 为测试用例标注测试级别编写测试用例时需要通过test_level()为用例显式分配级别若不加任何标注则默认为级别 0在每个测试阶段都会运行。标注方式如下摘自文档示例from modelscope.utils.test_utils import test_level class ImageCartoonTest(unittest.TestCase): unittest.skipUnless(test_level() 1, skip test in current test level) def test_run_by_direct_model_download(self): pass即使用unittest.skipUnless配合test_level() N做条件跳过当当前测试级别小于 N 时该用例被跳过。仓库内大量测试都遵循这一模式例如 tests/pipelines/test_image_matting.py 中test_run_with_dataset标注test_level() 1属于端到端功能测试加载damo/cv_unet_image-matting模型跑完整抠图流程test_run_modelhub标注test_level() 0作为基础功能用例始终运行其余更复杂的场景用例标注test_level() 2。2.4 运行测试的方式运行单个测试用例调试自己实现的功能直接执行测试文件即可若无法运行请检查并取消设置环境变量TEST_LEVEL。python tests/path/to/your_test.py本地核心测试在发起代码审查之前务必在本地环境运行核心测试默认只会运行级别 0 的用例make tests持续集成CI测试发起代码审查后会自动触发CI 会运行级别 1 的测试用例。每日回归测试每天凌晨 0 点基于 master 分支运行覆盖全部测试用例即级别 2 的全量场景测试。3. 测试数据存储git-lfs 与 data/test 子模块ModelScope 的测试数据包含大量图像、视频与模型权重等大文件因此采用git-lfs存储并以子模块方式挂载在data/test目录。3.1 安装 git-lfs版本 ≥ 2.5.0各平台安装方式如下Macbrew install git-lfs git lfs installCentOS从 git-lfs 的 GitHub Releases 页面下载对应 rpm 文件后安装sudo rpm -ivh your_rpm_file_name.rpm git lfs installUbuntucurl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash sudo apt-get install git-lfs git lfs install3.2 克隆子模块与更新测试数据仓库通过.gitmodules将data/test声明为子模块指向 ModelScope 的公共只读测试数据仓库见 .gitmodules。克隆仓库时需使用--recursive参数以同时拉取子模块git clone https://github.com/modelscope/modelscope.git --recursive每次添加新测试数据时按以下步骤操作进入data/test目录此时已处于子模块自己的 git 仓库中确认在 master 分支并拉取最新代码git branch git checkout master git pull origin master跟踪新的测试数据类型例如图片并在 master 分支上提交新文件cd data/test/ git lfs track *.png git add test.png git commit -m add test.png git push origin master返回 modelscope 仓库根目录提交子模块引用更新cd ../../ git add data/test git commit -m update test data注意默认情况下 ModelScope 组织下的所有成员拥有测试数据仓库的写权限。若遇到权限问题可发送邮件至 ModelScope 官方邮箱contactmodelscope.cn官方会安排专人联系处理。4. 开发与代码审查流程遵循文档推荐的分支协作模型一次完整的代码贡献包含以下步骤同步最新 master 并创建开发分支git pull origin master --rebase git checkout -b dev/my-dev-branch建议将dev/my-dev-branch替换为有意义的分支名如dev/fix-matting-bug并且每次改动都使用一个新的 dev 分支避免多个改动混在同一个分支中。进行本地修改完成代码编写与测试标注。提交本地更改commit message 遵循带工作项编号的规范格式git add . git commit -m [to #42322933] my commit message推送分支并构建 wheel 包用于自测安装git push --set-upstream origin dev/my-dev-branch bash make whl此后向同一分支推送可继续使用git push。创建 Pull Request在 GitHub 上将 dev 分支合并到 master等待 CI级别 1 测试通过后由维护者审查合并。5. 构建 pip 软件包开发完成后可通过 Makefile 的whl目标构建分发包make whl从 Makefile 的实现可以看到构建分为两步whl: python -c from modelscope.utils.ast_utils import generate_ast_template; generate_ast_template() python setup.py sdist --dist-dir $(WHL_BUILD_DIR)/dist bdist_wheel --dist-dir $(WHL_BUILD_DIR)/dist第一步调用 modelscope/utils/ast_utils.py 中的generate_ast_template()生成 AST 索引模板ModelScope 依赖 AST 静态分析来注册模型/流水线等组件打包前必须重新生成以保证索引与源码一致第二步执行python setup.py同时产出源码分发包sdist与 wheel 二进制包输出目录为package/dist。构建产物可直接用pip install package/dist/*.whl安装验证。小结围绕 docs/source/develop_cn.md 这份官方开发文档本文完整还原了 ModelScope 的研发规范全貌PEP8 flake8/yapf/isort pre-commit 构成的自动化代码检查体系、三级测试分级与TEST_LEVEL环境变量的控制机制、基于 git-lfs 与data/test子模块的测试数据管理、标准化的分支开发与审查流程以及make whl的打包细节。无论是贡献新模型、修复 pipeline 缺陷还是参与框架核心开发这套流程都定义了从写代码到合入 master的每一道质量关卡。【免费下载链接】modelscopeModelScope: bring the notion of Model-as-a-Service to life.项目地址: https://gitcode.com/GitHub_Trending/mo/modelscope创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
