Skip to content

Update setuptools-scm requirement from >=3.5.0 to >=9.2.2#350

Open
dependabot[bot] wants to merge 1 commit intomainfrom
dependabot/pip/setuptools-scm-gte-9.2.2
Open

Update setuptools-scm requirement from >=3.5.0 to >=9.2.2#350
dependabot[bot] wants to merge 1 commit intomainfrom
dependabot/pip/setuptools-scm-gte-9.2.2

Conversation

@dependabot
Copy link
Copy Markdown
Contributor

@dependabot dependabot Bot commented on behalf of github Apr 14, 2026

Updates the requirements on setuptools-scm to permit the latest version.

Changelog

Sourced from setuptools-scm's changelog.

v9.2.2

Fixed

  • fix #1231: don't warn about tool.setuptools.dynamic.version when only using file finder. The warning about combining version guessing with setuptools dynamic versions should only be issued when setuptools-scm is performing version inference, not when it's only being used for its file finder functionality.

v9.2.1

Fixed

  • fix #1216: accept and create a warning for usages of version = attr: in setuptools config. unfortunately dozens of projects cargo-culted that antipattern

v9.2.0

Added

  • add simplified activation via setuptools-scm[simple] extra

    A new streamlined way to enable version inference without requiring a [tool.setuptools_scm] section. When setuptools-scm[simple] is in build-system.requires and version is in project.dynamic, version inference is automatically enabled with default settings.

Removed

  • unchecked simplified activation - too many projects use setups where it would fail

Changed

  • refine activation logic and add unittest for the relevant cases instead of trying to speedrun setuptools

v9.1.1 (yanked)

Fixed

  • fix #1194: correctly handle version keyword when pyproject metadata is missing

v9.1.0 (yanked)

Fixed

  • complete reiteration of the decision logic for enabling version inference on setuptools_scm

... (truncated)

Commits
  • e56b78f Merge pull request #1232 from RonnyPfannschmidt/fix-1231-dont-warn-when-no-guess
  • 4f55e95 docs: update changelog for v9.2.2 patch release
  • 95a0c47 fix: don't warn about tool.setuptools.dynamic.version when only using file fi...
  • 338f562 Merge pull request #1226 from RonnyPfannschmidt/prepare-release
  • a893634 Prepare release v9.2.1
  • ad83282 Merge pull request #1225 from pypa/pre-commit-ci-update-config
  • 20a4464 [pre-commit.ci] pre-commit autoupdate
  • 70f6942 Merge pull request #1219 from RonnyPfannschmidt/fix-1216-explicitly-deprecate...
  • 14d85c0 Install Mercurial on Windows runners via Chocolatey
  • 8c5cec9 Fix API stability check workflow to install griffe and improve reporting
  • Additional commits viewable in compare view


Note

Low Risk
Low risk: only updates the build-time setuptools_scm[toml] version constraint, with no runtime code changes.

Overview
Updates pyproject.toml to require setuptools_scm[toml]>=9.2.2 (from >=3.5.0) in the build system dependencies, allowing newer setuptools-scm versions during packaging/builds.

Reviewed by Cursor Bugbot for commit 58c4bfa. Bugbot is set up for automated code reviews on this repo. Configure here.

@dependabot dependabot Bot added Changed Required label for PR that categorizes merge commit message as "Changed" for changelog dependencies Pull requests that update a dependency file python Pull requests that update Python code labels Apr 14, 2026
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Apr 14, 2026

🤖 Cursor Dependency Analysis

Supply-Chain Malware Review

Reviewing how setuptools-scm is declared in the project and what the scan flagged. Exploring the repository.

Verdict: benign

Reasoning

  1. Package and source
    The dependency is setuptools-scm (setuptools_scm on PyPI) from pypa, the standard maintainers. That is not typosquatting, and your project already wires it as a normal PEP 518 build dependency with [tool.setuptools_scm] (see root pyproject.toml).

  2. Classic obfuscation / exfiltration
    The update is a version floor change (>=3.5.0>=9.2.2); it does not add code, scripts, or network behavior to your repo. There is no evidence in the report of obfuscated payloads, unexpected install hooks, or lockfile hash anomalies (scanner: 0 unicode/confusable/IOC).

  3. Invisible Unicode
    Scanner: 0 post-allowlist unicode findings — no GlassWorm-style signal from this run.

  4. Scanner vs interpretation

    • ghost_version_or_missing_tag for >=9.2.2: Likely a false positive: PEP 440 ranges are not a single git tag; v9.2.2 is a documented release on the real upstream repo.
    • maintainer_drift / npm-maintainers: Heuristic is mismatched to ecosystem (npm pattern on a PyPI package) and a large jump from an old floor is expected for this bump — not evidence of account takeover by itself.
    • workflow_path_touch on .github/workflows/… and .pre-commit-config.yaml: The report’s resolution_strategy: commit_list and “changed upstream files” indicate these are files touched in the upstream setuptools-scm commit range, not proof your app PR silently rewrote your CI. Treat as noisy, not malicious unless your actual PR diff includes unexpected workflow edits in this repo (verify the real PR git diff for chiavdf).
  5. Dependabot context
    Bumping a build-system requires line for a core packaging tool is normal; the changelog you quoted is bugfix/behavioral (warnings, activation logic), not red flags for supply-chain malware.

Actionable follow-up (non-malware): Run your usual pip install/wheel build in CI to catch any compatibility issues with setuptools 82+ and setuptools-scm 9.x, not for malware.

Compatibility Analysis

Searching the repository for setuptools-scm usage and inspecting build configuration.

1) Where it’s used (chiavdf)

  • Build only: setuptools_scm appears in pyproject.toml under [build-system].requires (as setuptools_scm[toml]…) and in [tool.setuptools_scm] for VCS-based versioning (fallback_version, local_scheme). It is not listed as a runtime install requirement for the package.
  • Indirect use in setup.py: the CMake build passes self.distribution.get_version() into CXXFLAGS as VERSION_INFO — that string comes from the setuptools version metadata, which setuptools-scm supplies at build time.
[build-system]
requires = ["setuptools>=82.0.1", "wheel", "setuptools_scm[toml]>=9.2.2", "pybind11>=2.10.0"]
build-backend = "setuptools.build_meta"

[tool.setuptools_scm]
fallback_version = "unknown-no-.git-directory"
local_scheme = "no-local-version"
  • No import setuptools_scm in first-party src/ / tests/ (only vendored/copied under .upstream-dependency/, which is not how you ship the library).
  • No setup.cfg and no version = attr:… pattern here; the recent changelog items about tool.setuptools.dynamic.version + file-finder and version = attr: do not map to this layout.

Note: Your workspace already pins >=9.2.2; the PR is still correctly characterized as “raise the floor from 3.5.0 to 9.2.2” relative to the previous branch state.


2) Overlap with upstream changes (9.2.x notes + .upstream-dependency)

  • This repo uses explicit [tool.setuptools_scm] and the [toml] extra, not the new setuptools-scm[simple] / “dynamic version in project only” paths highlighted in the release notes.
  • The 9.1+ work on when version inference runs and the 9.2.1/9.2.2 warning fixes target setups mixing setuptools dynamic metadata, version = attr:, or file-finder–only use — not your current “classic setup.py + tool.setuptools_scm” pattern.

So: low intersection with the controversial behavior changes; you’re on the “normal” VCS version path.


3) Risks / unknowns

  • Build environment only: any regression shows up in sdist/wheel builds and version strings (e.g. unknown-no-.git-directory when .git is missing), not in import chiavdf at runtime.
  • Very old build stacks (ancient pip / broken isolation) could have more trouble meeting >=9.2.2; you already pair with setuptools >=82, which is consistent with current setuptools-scm.
  • Shallow/CI checkouts: already guarded by fallback_version; only verify the resulting version/metadata is what you want in those jobs.

4) Recommendation

merge (or merge-with-caveats if you want CI to re-check): treat as a build-tool floor bump with no in-tree Python API usage and no overlap with the warning-heavy edge cases in the 9.2.x changelog. Caveat: run your usual build / cibuildwheel path once on the PR so the computed version and VERSION_INFO in CMake still look correct in real CI conditions.


Malware Scan Summary

  • Status: warn
  • Warn only mode: true
  • Changed upstream files scanned: 3
  • Resolution strategy: commit_list
  • Changed node/vendor paths: 0
  • Changed lockfiles: 0
  • Resolved refs: from=n/a to=n/a
  • Unicode findings (post-allowlist): 0
  • Confusable findings (post-allowlist): 0
  • IOC findings (post-allowlist): 0
  • Heuristic findings (post-allowlist): 4

Top findings

  • .github/workflows/api-check.yml:0 workflow_path_touch :: path-touch
  • .github/workflows/python-tests.yml:0 workflow_path_touch :: path-touch
  • setuptools-scm:0 ghost_version_or_missing_tag :: >=9.2.2
  • setuptools-scm:0 maintainer_drift :: >=3.5.0->>=9.2.2

@dependabot dependabot Bot force-pushed the dependabot/pip/setuptools-scm-gte-9.2.2 branch from b91b75c to 3b39916 Compare April 22, 2026 15:19
Updates the requirements on [setuptools-scm](https://github.com/pypa/setuptools-scm) to permit the latest version.
- [Release notes](https://github.com/pypa/setuptools-scm/releases)
- [Changelog](https://github.com/pypa/setuptools-scm/blob/v9.2.2/CHANGELOG.md)
- [Commits](pypa/setuptools-scm@setuptools-scm-v10.0.0...v9.2.2)

---
updated-dependencies:
- dependency-name: setuptools-scm
  dependency-version: 9.2.2
  dependency-type: direct:development
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot force-pushed the dependabot/pip/setuptools-scm-gte-9.2.2 branch from 3b39916 to 58c4bfa Compare April 22, 2026 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Changed Required label for PR that categorizes merge commit message as "Changed" for changelog dependencies Pull requests that update a dependency file python Pull requests that update Python code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants