pyproject.toml: [tool.setuptools_scm] is inert — maturin takes the version from Cargo.toml
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 45/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 领域
- build-system, release
调研方向
The inert section is [tool.setuptools_scm] near line 110 of pyproject.toml, while dynamic = ["version"] on line 7 is resolved by maturin from rust/Cargo.toml. Confirm that by building a wheel and checking its version against Cargo.toml. Done means the maintainers have picked an option: either remove the section so Cargo.toml is clearly the single source, or make SCM actually drive the version. Optionally add a tag-vs-version check to the publish workflow. The issue has no comments yet, so pick the direction with a maintainer first.
由索引模型根据 Issue 内容生成。
描述
Third one from modelling ddx's packaging on this repo (after #242 and #243) — this one I checked empirically rather than by reading, because I was about to copy the pattern.
pyproject.toml declares SCM versioning:
[project]
dynamic = ["version"] # L7
...
[tool.setuptools_scm] # L110
but setuptools-scm is never installed at build time:
[build-system]
requires = ["maturin>=1.9,<2.0"]
build-backend = "maturin"
and maturin is the backend, not setuptools — it does not consult setuptools-scm at all. For dynamic = ["version"], maturin takes the version from Cargo.toml.
How I checked
I put the identical configuration on ddx's own maturin package — dynamic = ["version"], [tool.setuptools_scm], and (unlike here) setuptools-scm actually present in build-system.requires — in a repo with no matching git tag at all. SCM versioning would have had to produce a 0.1.x.dev...+g<sha> string. The build produced:
📦 Built wheel ... ddxdb-0.1.0-cp310-abi3-macosx_11_0_arm64.whl
0.1.0 is exactly the Cargo.toml version. Git was never consulted.
So [tool.setuptools_scm] here is inert configuration: the published version is whatever rust/Cargo.toml says, and the section reads as though tags drive it. That is harmless today but misleading — someone bumping a tag and expecting the wheel to follow would be surprised, and the failure is silent.
Options
- Drop
[tool.setuptools_scm]and treatrust/Cargo.tomlas the single source, which is what already happens. Optionally assert tag-vs-version in the publish workflow so a mismatched tag fails the release rather than shipping. - Actually use SCM, which means not using maturin's version handling — e.g. generate the version in CI and pass
--version/ rewriteCargo.tomlbefore building. More machinery than it is likely worth.
I went with (1) plus a tag check in ddx. Happy to send a PR here if useful.
- 主要语言
- Python
- 星标
- 142
- 派生
- 19
- 平均合并
- 1 天 9 小时
- 30 天内合并 PR
- 9
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
xqlsystems/xarray-sql 的其他 Issue
-
documentation
难度 1/5 1-3 小时 新手友好度 85/100
xqlsystems/xarray-sql#268 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 64/100
xqlsystems/xarray-sql#267 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 74/100
xqlsystems/xarray-sql#243 ·
维护者通常 1 天内回复
-
publish.yml: the TestPyPI verification step is unreachable (and installs the wrong package name)未关闭
难度 2/5 1-3 小时 新手友好度 62/100
xqlsystems/xarray-sql#242 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
xqlsystems/xarray-sql#237 ·
维护者通常 1 天内回复
查看 xqlsystems/xarray-sql 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
-
changelog investigate
难度 2/5 1-3 小时 新手友好度 65/100
ramnes/notion-sdk-py#423 ·
-
type-bug
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复