feat: add dynamic-metadata integration#1465
Conversation
Ship a `vcs_versioning.dynamic_metadata` provider for scikit-build/dynamic-metadata so any PEP 517 backend can infer a VCS-derived version from `[tool.vcs-versioning]` with no glue code. The provider wraps the public integrator API (PyProjectData.from_file + infer_version_string within a GlobalOverrides context). It reads config from `[tool.vcs-versioning]`, forwards extra table keys as overrides, and supports only the `version` field. Targets the standalone dynamic-metadata signature `dynamic_metadata(settings, project)`. Assisted-by: ClaudeCode:claude-opus-4-8
a1eda7e to
7718b7e
Compare
Drop some things added by Claude in the first commit that are not needed: * The `field` setting - it's always version * The requirements hook that was returning this package * The addition to integrators doc that (AFAICT) isn't helpful * Local imports (this _is_ vcs-versioning, no need to local import it!) Also avoiding stating that all PEP 517 backends support this (they don't!), and avoiding adding scikit-build in front of every mention.
7718b7e to
99ff436
Compare
Signed-off-by: Henry Schreiner <[email protected]>
7a6bd2d to
eb21ab6
Compare
Signed-off-by: Henry Schreiner <[email protected]>
81799c8 to
c99b4c8
Compare
| ```toml | ||
| [[tool.dynamic-metadata]] | ||
| provider = "vcs_versioning" | ||
| local_scheme = "no-local-version" |
There was a problem hiding this comment.
imho dynamic metadata should have a wy to pass in the root pyproject directly - and the vcs-versioning provider should use its own tool section for the configuration - creating additional placees for putting the same thing is against the zen of python as far as im concerned
There was a problem hiding this comment.
It does, hooks run in the same directory as build-system.build-backend so it's fine to read it. That's why the docs say both work. You can disable this (don't pass through config, require to be empty), but users will likely expect to have all the config in each tool.dynamic-metadata section. And if you use it multiple times (like building readme's out of fragments), you have to have it in each entry.
| version = vcs_versioning.infer_version_string( | ||
| dist_name=dist_name, | ||
| pyproject_data=pyproject, | ||
| overrides=dict(settings) or None, |
There was a problem hiding this comment.
This is the line that makes [[tool.dynamic-metadata]] <stuff> work (other than provider, which is baked in).
| with vcs_versioning.overrides.GlobalOverrides.from_env( | ||
| "VCS_VERSIONING", dist_name=dist_name | ||
| ): | ||
| pyproject = vcs_versioning.PyProjectData.from_file("pyproject.toml") |
There was a problem hiding this comment.
And this is the line that makes tool.vcs-versioning work :). Fully configurable. :)
| create-release-proposal = "vcs_versioning_workspace.create_release_proposal:main" | ||
|
|
||
| [project.entry-points."dynamic_metadata.provider"] | ||
| "vcs_versioning" = "vcs_versioning._dynamic_metadata" |
There was a problem hiding this comment.
Ahh, I put this in the wrong pyproject.toml. Sorry! Will move soon. I wondered why I didn't see any other entry-points.
Signed-off-by: Henry Schreiner <[email protected]>
Signed-off-by: Henry Schreiner <[email protected]>
This is a draft implementation of dynamic-metadata (0.3 version), to evaluate if this is something interesting to add. Also see https://discuss.python.org/t/dynamic-metadata-the-package/107953 and https://dynamic-metadata.readthedocs.io for more info. Currenly, only the upcoming scikit-build-core 1.0 supports
tool.dynamic-metadata, but I'm also planning to contribute it to meson-python, and would like to see if other backends are intersted in supporting it.This replaces the (now deprecated)
scikit_build_core.metadata.setuptools_scmplugin. There is not a matchingdynamic_metadata.plugins.setuptools_scmplugin.I did an initial plan and commit with Claude (Opus 4.8), then removed about half of what it did that wasn't needed in the clean up commit (both commits are present here for inspection). I left the "integrations" section where it put it (first), but I can move it easily, just let me know where it should be moved.
Question: Should this hook be available at top level, so provider can just be "scm_versioning"?