Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Performance] packaging and release improvements and cleanup

未关闭
#925 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
冷清
技术栈
github-actions, python

调研方向

先查看 pyproject.toml、MANIFEST.in、release.yml、xblock/init.py 和 docs/conf.py,然后比较 openedx/xblocks-extra 中的打包和发布配置。使用 python -m build 构建 package,并使用提供的 zipfile 命令检查生成的 wheel 内容。当 src/ 布局、package 内容、changelog 决策、semantic-release 行为以及 release build 都按预期工作时,即表示完成。

由索引模型根据 Issue 内容生成。

描述

performance

Context

Follow-up work after #917 (folding web_fragments into the XBlock project).

Tasks

1. Drop __version__ from xblock/__init__.py and unused Sphinx import

As noted in this comment:

Ideally we should drop __version__ from xblock/__init__.py since we've shifted to semantic versioning. The only reason it still exists is that docs/conf.py imports it for Sphinx — but that import is unused too (no .rst file references version), so both can be removed together.

  • Remove __version__ from xblock/__init__.py
  • Remove the corresponding unused import in docs/conf.py
2. Migrate to src/ layout

Move both xblock and web_fragments packages under a src/ directory to follow modern Python packaging conventions and prevent accidental imports from the repo root during development.

  • Create src/ directory
  • Move xblock/ → src/xblock/
  • Move web_fragments/ → src/web_fragments/
  • Update pyproject.toml (package-dir = {"" = "src"}, where = ["src"])
3. Optimize bundling via MANIFEST.in

The current MANIFEST.in is a single line:

recursive-include xblock *.mo *.po

With include-package-data = true and no exclusions, the built wheel ends up bundling a large number of files that have no business being in a distribution — including the entire docs/ tree (79 files), CI configs, linting configs, lock files, and dev tooling. This inflates the master wheel to ~1.1MB when it should be well under 200KB.

Taking inspiration from openedx/xblocks-extra's MANIFEST.in, MANIFEST.in should be updated to explicitly prune everything that isn't needed by an end user:

recursive-include xblock *.mo *.po
recursive-include web_fragments *.html

# Exclude development, CI, and documentation folders
prune .github
prune docs

# Exclude root-level config and build files
exclude .coveragerc
exclude .gitignore
exclude .readthedocs.yaml
exclude Makefile
exclude catalog-info.yaml
exclude codecov.yml
exclude conftest.py
exclude openedx.yaml
exclude pylintrc
exclude pylintrc_tweaks
exclude tox.ini
exclude uv.lock

# Exclude nested test files
global-exclude tests/*
global-exclude test_*.py

Files currently git-tracked at the repo root that should be excluded:

File Reason to exclude
Makefile Developer tooling
conftest.py pytest root config
.coveragerc Coverage tooling
.gitignore VCS config
.readthedocs.yaml Docs CI config
catalog-info.yaml Backstage catalog metadata
codecov.yml CI coverage reporting
openedx.yaml Open edX repo metadata
pylintrc, pylintrc_tweaks Linting config
tox.ini Test runner config
uv.lock Dependency lock file
docs/ Full documentation tree (79 files, major bloat source)
.github/ GitHub Actions and templates

Note: CHANGELOG.rst exclusion is covered by task 5.

4. Review whether tests should ship in the wheel

Currently both xblock/test/ and web_fragments/tests/ are included in the built wheel. This needs a deliberate decision:

  • Some of xblock/test/ contains base test classes and utilities (e.g. toy_runtime.py, tools.py) that downstream packages depend on — those should ship
  • Pure test files (e.g. test_fields.py, test_core.py) have no value for end users — those should not ship
  • web_fragments/tests/ — evaluate the same way

Suggested outcome: ship xblock/test/ selectively (keep test utilities) and exclude web_fragments/tests/ entirely.

5. Remove CHANGELOG.rst if no longer needed

Since XBlock has shifted to semantic release, release notes are managed via GitHub Releases automatically. CHANGELOG.rst may be redundant — study how openedx/xblocks-extra handles this.

In xblocks-extra, CHANGELOG.rst was dropped (along with its MANIFEST.in reference) because changelog: false is set in release.yml, meaning semantic release manages release notes entirely via GitHub Releases.

  • Verify XBlock's release.yml configuration
  • If changelog generation is handled by semantic release, remove CHANGELOG.rst and its reference in MANIFEST.in

Reference: openedx/xblocks-extra#50

6. Fix semantic release build failures and improve the release process

Two issues surfaced after #917 was merged, both worth addressing:

a) refactor commits silently skip a release

After #917 merged (using refactor: commit prefixes), the semantic release workflow ran but produced no release — because neither chore nor refactor is configured as a version-bumping commit type. The full log from that run:

INFO     No commits found since the last release!
INFO     The type of the next release release is: no_release
INFO     No release will be made

Reference: actions/runs/27294163918, PR #917 comment

A refactor that adds new functionality (like absorbing web_fragments) is arguably a feat and warrants a release. The fix is twofold:

  • Short-term: contributors should use feat: when a refactor introduces new capabilities available to users.
  • Long-term: consider adding refactor as a patch-level trigger in the semantic release config so accidental use of the wrong prefix doesn't silently suppress a release.

b) uv: command not found during the build step

A follow-up force-release PR (#926) did trigger a release, but the build step failed with exit code 127:

bash: line 1: uv: command not found
ERROR    Command '['bash', '-c', 'SETUPTOOLS_SCM_PRETEND_VERSION=$NEW_VERSION uv build']'
         returned non-zero exit status 127.
ERROR    Build command failed with exit code 127

Reference: actions/runs/27301129203/job/80647052902

The root cause: astral-sh/setup-uv (step 6 in release.yml) installs uv on the GitHub Actions runner, but python-semantic-release executes the build command inside its own Docker container — where uv is not present.

Possible fixes:

  • Change build_command in pyproject.toml from uv build to pip install uv && uv build so uv is installed inside the container before use.
  • Or switch to python -m build (requires build as a dev dependency) to avoid the uv-in-container problem entirely.

Testing

To verify bundling changes, build the package locally and inspect the wheel contents:

python -m build

Then inspect what got bundled:

python3 -c "
import zipfile, sys
whl = sys.argv[1]
for f in sorted(zipfile.ZipFile(whl).namelist()):
    print(f)
" dist/XBlock-*.whl

This makes it easy to catch regressions like docs bloat, missing templates, or unwanted test files shipping in the wheel.

Reference

openedx/xblocks-extra follows a modernized packaging approach and is a good reference for how the above tasks can be implemented — particularly the src/ layout, MANIFEST.in structure, and pyproject.toml conventions.

Related

🤖 Generated with Claude Code

主要语言
Python
星标
470
派生
231
平均合并
2 天 22 小时
30 天内合并 PR
7

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

openedx/XBlock 的其他 Issue

查看 openedx/XBlock 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。