Mesop 发布流程全解：从版本号递增到 PyPI 正式发布（基于 docs/internal/publishing.md）
Mesop 发布流程全解从版本号递增到 PyPI 正式发布基于 docs/internal/publishing.md【免费下载链接】mesopRapidly build AI apps in Python项目地址: https://gitcode.com/GitHub_Trending/me/mesop导读本文是 Mesop用 Python 快速构建 AI 应用 UI 的开源框架官方发布流程的技术详解。它完整记录了如何为pip install mesop发布新版本先评估 main 分支健康度与安全告警再按 semver 递增mesop/version.py并打 RCrelease candidate预发布随后通过 GitHub Release 触发 CI 自动构建 wheel 并发布到 PyPI最后用uvx冒烟测试、Gunicorn 集成测试与 Colab 实机验证确保发布质量。读完本文你将掌握 Mesop 从源码到 PyPI 的完整发布链路以及每一步背后的仓库实现细节版本注入、打包脚本、发布 Workflow、Colab 运行原理可直接复用到自建组件的版本发布场景。一、发布前检查main 分支健康与安全审计正式切版本之前官方要求先确认两件事main 分支处于健康状态最新提交的 CI 必须是绿色通过green。复查 Snyk 安全看板安全扫描每周只跑一次因此需要点击Retest now主动触发重测。如果 Mesop 核心文件如mesop/*下的任何文件存在High 级别的安全漏洞必须先在发布前修复。从仓库的实际 CI 配置看发布质量由多层流水线保障.github/workflows/ci.yml 负责常规的持续集成含单元测试、类型检查、E2E 测试等而 .github/workflows/release.yml 专门负责发布动作。CI 绿、安全无高危是切版本的前置门槛。二、递增版本号按 semver 生成 RC 预发布2.1 版本号的唯一真源Mesop 的版本号定义在 mesop/version.pyContains the version string. VERSION 1.3.4 if __name__ __main__: print(VERSION)这个文件的特殊性在于它被两处独立引用运行时注入mesop/init.py 中from mesop.version import VERSION并导出__version__ VERSION成为公开 API 的一部分供me.__version__在应用中读取打包注入mesop/pip_package/setup.py 特意注释说明故意不import mesop.pip_package.version因为那会通过mesop/__init__.py拖入 Flask 等第三方依赖而打包环境里这些包并不存在。它直接from version import VERSION保证 setup.py 可以在纯净环境中执行。这也是 mesop/pip_package/build_pip_package.sh 注释强调的version.py 被复制使用有两种方式1) 供 ./setup.py 使用2) 作为 mesop/init.py 的公开 API 常量。2.2 semver 与 RC 约定Mesop 遵循semver语义化版本。发布新版本时第一步永远先打 RCrelease candidate用于提前暴露问题。PyPI 会将rc后缀视为pre-release预发布不会进入默认的pip install mesop稳定版渠道。例如当前稳定版是0.7.0那么先递增为0.8.0rc1而不是直接发布0.8.0。修改mesop/version.py的 PR 合并后即可进入下一步发布 GitHub Release。三、发布 GitHub Release触发自动发布到 PyPI3.1 操作步骤版本号 PR 合并后在 GitHub 上创建新的 Release点击Choose a tag输入刚发布的版本号自动创建新的 Git tag点击Generate release notes自动生成发布说明如果是 RC勾选Set as a pre-release否则保持Set as the latest release勾选如果是正式版非 RC点击Create a discussion for this release创建讨论区帖子点击Publish release正式发布。3.2 背后自动化的发布链路Release 一经发布.github/workflows/release.yml 会立即被触发on: release: types: [published]执行两个 Jobrelease-build在ubuntu-latest上检出代码、安装 Python 3.10运行./scripts/build_pip.sh构建发布产物并上传为 artifact。pypi-publish下载产物后通过pypa/gh-action-pypi-publish发布到 PyPI并明确使用Trusted Publishingid-token: write权限 指向https://pypi.org/p/mesop的受保护 environment无需在 CI 中硬编码 PyPI token。构建脚本 scripts/build_pip.sh 内部调用 Bazel 打包并最终生成 wheel其核心逻辑在 mesop/pip_package/build_pip_package.sh复制mesop源码、LICENSE、MANIFEST.in、README.md、requirements.txt、setup.cfg、setup.py等到临时目录然后执行python setup.py bdist_wheel --python-tag py3。细节上有几个工程化亮点可复现构建通过export SOURCE_DATE_EPOCH15778368002020-01-01T00:00:00Z覆盖 zip 归档内的时间戳保证 wheel 构建可复现build_pip_package.sh确定性 tar.gz若输出目标是.tar.gz会使用自研的 mesop/pip_package/deterministic_tar_gz.py 生成确定性归档避免 gzip 头时间戳导致每次产物字节不一致入口点注册setup.py 注册控制台脚本mesop mesop.bin.bin:run_main这就是pip install mesop之后可以直接在终端敲mesop命令的由来前端资源随包分发package_data声明了mesop: [web/**/*]确保打包时带上浏览器端构建产物。四、本地冒烟测试Dev CLI 与 Gunicorn 集成前置条件本地需要先安装 uvuvx依赖它。4.1 Dev CLI 冒烟测试将下面的1.0.0替换为你刚发布的版本号执行cd scripts/smoketest_app/ uvx --refresh mesop1.0.0 main.py这条命令用uvx在隔离环境中安装指定版本的 Mesop 并启动开发服务器主要验证热重载hot reload是否正常工作版本号显示是否正确打开页面应看到Running mesop version: 你发布的版本。这正是仓库冒烟测试应用的设计目的——scripts/smoketest_app/main.py 中me.page(path/buttons)的页面第一行就输出me.text(Running mesop version: me.__version__)并渲染一个带on_click事件、可自增计数的 Button配合 scripts/smoketest_app/simple_slot_app.py包含inner_component.py/outer_component.py及其 JS 对应物覆盖了自定义组件、插槽、事件处理等核心能力的回归验证。4.2 Gunicorn 集成测试cd scripts/smoketest_app/ uvx --refresh --with mesop1.0.0 gunicornlatest main:me这里用uvx --with把指定版本的 Mesop 注入到临时环境再以Gunicorn作为 WSGI 服务器加载main:me启动应用验证生产部署形态下框架的可用性。main:me中的me正是 mesop/init.py 导出的模块级 WSGI 应用——该模块被改造成_WsgiAppModule模块本身可直接被 WSGI 服务器调用这也是 Mesop 能无缝挂到 Gunicorn 等 WSGI 服务器下的架构基础。五、Colab 实测验证 PyPI 预发布的真实可用性由于Google Colab 是从 PyPI 安装 Mesop的RC 上传到 PyPI 后必须在 Colab 上实测一遍。打开官方的 mesop_colab_getting_started.ipynb关键点必须显式pip installRC 版本因为pip默认不会安装 pre-release 版本即使它是最新版本。将第一个 cell 改为!pip install mesop0.X.Yrc1依次运行所有 cell确认输出正常展示在 Colab 中如果框架出错通常表现很直观——比如输出不显示等。提示PyPI 仓库在上传后可能需要约一分钟才完成索引同步失败的话稍后重试即可。仓库侧的 Colab 运行机制可以佐证这一点mesop/colab/colab_run.py 中colab_run会检测是否处于 Colab 环境colab_utils.is_running_in_colab()是则通过 notebook_run 在后台线程启动 Flask 服务器默认端口 32123并调用log_startup打印启动日志——所以在 Colab 里运行me.colab_run()后能看到服务器的启动输出任何启动失败都会第一时间暴露。六、RC 转正式版收尾与复测若测试中发现问题回到上面的流程再产出一个新的 RC例如0.8.0rc1→0.8.0rc2重复发布与测试循环。若所有测试通过更新 mesop/version.py把版本从 RC 改为正式版例如0.8.0rc1→0.8.0。然后重做上述发布与测试的全部步骤——发布正式 GitHub Release勾选 Set as the latest release、创建讨论帖并再次跑 Dev CLI、Gunicorn、Colab 三套验证直到正式版稳定上线。七、总结完整发布检查清单阶段关键动作验证方式仓库依据发布前main 分支 CI 绿、Snyk 无核心高危CI 状态 Retest now.github/workflows/ci.yml打 RC按 semver 递增 version.py如0.8.0rc1合并 PRmesop/version.py发布创建 GitHub ReleaseRC 勾 pre-releaseRelease 触发自动发布.github/workflows/release.yml本地验证uvx --refresh mesopx.y.z main.py热重载 版本号显示scripts/smoketest_app/main.pyGunicornuvx --with mesopx.y.z gunicornlatest main:me生产形态可启动mesop/init.pyColab显式!pip install mesop0.X.Yrc1运行全部 cell 输出正常notebooks/mesop_colab_getting_started.ipynb转正式0.8.0rc1→0.8.0重跑全部验证重复上述流程mesop/version.py这条发布链路在工程上非常完整版本号单一真源mesop/version.py同时服务运行时与打包发布动作完全由 GitHub Release 事件驱动、使用 Trusted Publishing 免密发布到 PyPI打包脚本通过SOURCE_DATE_EPOCH与确定性 tar 实现可复现构建验证环节覆盖开发态Dev CLI 热重载、生产态Gunicorn与云端 notebook 态Colab三种典型运行场景。对希望为 Mesop 贡献组件或自建类似发布管线的开发者而言这套流程docs/internal/publishing.md本身就是一份可直接照搬的工程范本。【免费下载链接】mesopRapidly build AI apps in Python项目地址: https://gitcode.com/GitHub_Trending/me/mesop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考