Repository navigation
Sync: main → develop - #1552
Merged
Merged
Sync: main → develop#1552
Conversation
A project whose pyproject.toml sits in a subdirectory of a checkout still shipped an sdist and a wheel with none of its tracked files. root defaults to the project directory, which is not the checkout root, so version inference correctly found no SCM there and answered from SETUPTOOLS_SCM_PRETEND_VERSION or fallback_version. The egg_info mixin read that no-workdir as "there is no checkout" and suppressed the file finders, so every file setuptools' own package discovery does not find was dropped. This is the same shape as #1540 and survived its fix in 10.3.3. That fix stopped "never looked" from aliasing "looked and found nothing"; what is left is that "found nothing at root" is not "there is no checkout". The finders that 10.2.3 fell through to were never scoped by root -- they walk up from the working directory -- which is why the layout worked before 10.3.0 and why the suppression is what broke it. Which checkout defines the version and which checkout holds the files are different questions. root and search_parent_directories scope the first on purpose; the second follows the checkout the project physically sits in. discover_file_workdir answers it: parents are always searched, only live SCM checkouts qualify, IGNORE_VCS_ROOTS still excludes a root, and the listing is scoped to project_root so a monorepo sibling's files stay out. project_path is deliberately not verified there. config.project_path is measured from the declared root and a workdir's from the real checkout, and this discovery only runs when those differ -- so the two disagree by construction. Verifying would raise on a layout that built fine in 10.2.3, or discard a correct file list, over a value file listing never reads. VersionInferenceData.file_workdir caches it next to the lazy workdir, so the two consumers (find_sources and the egg-info metadata writer) share one discovery instead of probing twice. Routing these projects through the deprecated setuptools.file_finders entry point would also have restored the files, and more cheaply. It was rejected for shipping a worse sdist: that path writes no scm_file_list.json, so a rebuild from the sdist has no file list to fall back on, and it parks the fix on a path already slated for removal. Fixes #1543 Co-Authored-By: Claude Opus 5 (1M context) via Claude Code <noreply@anthropic.com>
…llows-the-checkout fix(file-discovery): follow the checkout, not the versioning root
The floor check imported every setuptools_scm submodule and called that a compatibility claim. It is not: the integration hooks reach for vcs-versioning internals from inside function bodies, and a deferred import is invisible to an import probe. setuptools-scm 10.3.4.dev imports vcs_versioning._worktree_discovery.discover_file_workdir inside build_py._file_workdir, added after 2.4.1 and in no published release, while declaring >=2.4.0.dev0 -- the probe stayed green. Install the test requirements alongside the wheel, before the core is pinned so they cannot drag it back up, and run setuptools-scm/testing_scm from the workspace root. Root is where the other jobs run pytest; run from setuptools-scm/ the suite picks up ambient repository state and fails on tests that have nothing to do with the floor. The testsuite is the checkout's, so it loads vcs_versioning.test_api from the pinned floor release: a test helper added to the core after the floor also fails here. That is not the floor claim proper, but it reads the same way -- this tree needs a newer core than it declares. Co-Authored-By: Claude Opus 5 (1M context) via Claude Code <noreply@anthropic.com>
#1544 made build_py._file_workdir import vcs_versioning._worktree_discovery.discover_file_workdir, added to the core in that same change and in no published release, while the declared floor stayed at 2.4.0.dev0. An install that resolves a published vcs-versioning raises ImportError from the file-discovery path -- the one #1543 was about. 2.5.0 is what the core's towncrier-fragments scheme computes for the pending feature fragment, so the workspace build satisfies the new floor. A checkout synced before this needs `uv sync --reinstall-package vcs-versioning`: uv caches the editable metadata, and a stale 2.4.0.dev version fails the builds the testsuite runs. Co-Authored-By: Claude Opus 5 (1M context) via Claude Code <noreply@anthropic.com>
…runs-the-testsuite ci: the vcs-versioning floor check runs the testsuite
setuptools-scm 10.1.0 through 10.2.3 call _version_missing(config, tool=env.tool_names[0]) and allow any vcs-versioning<3. 78e3451 dropped the keyword in the 2.4.1 patch release, so with 10.2.3 (the newest non-yanked setuptools-scm on PyPI) a build without a detectable version fails with TypeError: _version_missing() got an unexpected keyword argument 'tool' instead of the LookupError that tells the user how to set a version. Accept the keyword and ignore it: those callers passed config.env.tool_names[0], which is what the function reads now. With this change setuptools-scm 10.2.3's testing_scm passes against vcs-versioning (181 passed; 1 failed against 2.4.1). Fixes #1550 Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
…ccepts-tool fix(vcs-versioning): accept tool= in _version_missing again
Release: setuptools-scm v10.3.4, vcs-versioning v2.5.0
…lure setuptools-scm 10.3.3 was tagged on 2026-09-16 and reached PyPI a week later (#1549). One flaky Windows test failed in its release run, which skips dist_upload_setuptools_scm, and nobody noticed because every release run was red anyway: create-release-tags.yml created published, immutable releases, so upload-release-assets-* failed every time. - create-release-tags.yml pushes the tag itself and creates the release as a draft (a draft does not create its tag, and the dispatch needs it). - publish-github-release-* replace upload-release-assets-*: after the PyPI upload they attach the wheel and sdist to the draft and publish it. A release left in draft never reached PyPI. - release-failed opens a "Release <tag> did not publish" issue when a tag run fails or is cancelled, or comments on the open one. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
python-tests.yml reports failures of the release runs it is dispatched for, but when create-release-tags.yml itself fails those runs never start and nothing reported it. Its release-failed job opens (or comments on) a "Release from #<PR> did not start" issue. Workflow-level write permissions move onto create-tags, since the file now has a second job that only needs issues: write. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
The release-failed jobs used gh in bash. create-release-tags.yml already runs on github-script, and gh issue list --search goes through the search index, which lags behind newly created issues, so a quick second failure could miss the open issue and file a duplicate. Listing open issues and matching the title exactly avoids that, and the PR title and tag no longer pass through a shell. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
The last gh calls in the workflows. getReleaseByTag does not return drafts, so the draft is found through listReleases, stopping at the first page that has it. Assets already attached are skipped, so a re-run after a partial upload publishes instead of failing on the duplicate; a release that is missing or already published fails with a message naming the tag. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
Bumps [urllib3](https://github.com/urllib3/urllib3) from 2.2.3 to 2.8.0. - [Release notes](https://github.com/urllib3/urllib3/releases) - [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst) - [Commits](urllib3/urllib3@2.2.3...2.8.0) --- updated-dependencies: - dependency-name: urllib3 dependency-version: 2.8.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
chore(deps): Bump urllib3 from 2.2.3 to 2.8.0
…eme (#1556) * feat(vcs-versioning): add the towncrier-fragments-zerover version scheme towncrier-fragments proposes the next major for any major, breaking or removal fragment, so a 0.x project with one removal fragment proposes 1.0.0. The zerover variant keeps 0.x on 0.x: while the last tag's major is 0, breaking and removal bump the minor version and only an explicit major fragment proposes 1.0.0. towncrier-fragments is unchanged. Also documents both towncrier schemes in docs/extending.md, where towncrier-fragments was not listed. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com> * chore: number the changelog fragment after the PR Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
…nnable release-failed reported test-dependency-floor and test-standalone-vcs-versioning failures as "did not publish", but the upload only waited for `test`, so a floor failure in a vcs-versioning release opened that issue for a package already on PyPI. The uploads now wait for every job release-failed reports on, and check that the built files carry the tag's version before publishing. create-release-tags.yml created both tags and drafts before dispatching, so a failure on the second package stranded the first, and a re-run failed on the existing tag. It now reuses a tag already at the merge commit and an existing release, skips releases already published, and does not dispatch a tag that already has a release run: a second dispatch would share its concurrency group and cancel a run that may be uploading. Publishing a release closes its "did not publish" issue, and a successful re-run of the tagging closes its "did not start" issue. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
ci(release): publish GitHub releases after PyPI, open an issue on failure
Release: vcs-versioning v2.6.0
Read the Docs serves the project as multiple_versions_without_translations, so /en/... URLs returned 404 until a redirect was added (#1547). The error messages in vcs-versioning and the setuptools-scm README, which is also the PyPI project page, now link the paths Read the Docs serves. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
Merging #1553 and then #1557 48 seconds apart raced: the proposal run for #1553's merge commit still saw the 2.6.0 fragment, force-pushed release/main three seconds after #1557 was merged, found no open release PR and opened #1558, a duplicate of the release that had just shipped. Merging it would have re-run the 2.6.0 tagging. The push step now stops when the source branch no longer points at the run's commit; the run for the newer commit proposes the release. A push that finds no fragments in either package closes any release PR still open for its branch, unless the branch has moved on, so a duplicate that slips through anyway does not linger. Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
…ut-language-prefix docs: link the docs without the /en/ language prefix
ci(release-proposal): do not propose from a superseded commit
…updates Bumps the github-actions group with 2 updates in the / directory: [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) and [msys2/setup-msys2](https://github.com/msys2/setup-msys2). Updates `astral-sh/setup-uv` from 10.0.1 to 10.2.0 - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@20cfd1b...c18668a) Updates `msys2/setup-msys2` from 2.32.0 to 2.33.0 - [Release notes](https://github.com/msys2/setup-msys2/releases) - [Changelog](https://github.com/msys2/setup-msys2/blob/main/CHANGELOG.md) - [Commits](msys2/setup-msys2@66cd2cc...ec48f7c) --- updated-dependencies: - dependency-name: astral-sh/setup-uv dependency-version: 10.2.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: msys2/setup-msys2 dependency-version: 2.33.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
…ctions-3ebff4a8e7 chore(deps): Bump the github-actions group across 1 directory with 2 updates
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Branch Synchronization
Syncs release changes from
mainback todevelopafter merging Release: setuptools-scm v10.3.4, vcs-versioning v2.5.0.This is an automated PR created by the branch-sync workflow.
Review and merge to keep
developup to date withmain.