📦 Pass desired release to PEP 517 tox env

[webknjaz]

This patch fixes passing the release version string from the release automation script to the tox's PEP 517 frontend, so that the backend machinery bits (namely, setuptools-scm) could access the environment variable; as indentified in the attempt to release pytest v9.0.1 [1].

The solution uses the [pkgenv] section of tox.ini that corresponds to the PEP 517 build env tox manages internally.

[webknjaz]

📚 https://pytest--13933.org.readthedocs.build/en/13933/changelog.html#packaging-updates-and-notes-for-downstreams

[Copilot]

Pull Request Overview

This PR fixes the release automation to properly pass the version string to the PEP 517 build environment managed by Tox. The key issue was that setuptools-scm needs access to the SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST environment variable during the wheel build process, not just during test execution.

• Moved SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PYTEST from [testenv] to [pkgenv] section to make it available during PEP 517 build
• Removed redundant passenv declarations from specific testenvs ([testenv] and [testenv:regen])
• Added comprehensive documentation comments explaining the [pkgenv] section usage and workarounds for tox v4.14.1 regression

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
tox.ini	Restructured environment variable passing to make version string available in PEP 517 build environment instead of only in test environments
changelog/13933.packaging.rst	Added changelog entry for the packaging fix (contains an error in content)
changelog/13933.contrib.rst	Contains the actual changelog content describing the tox configuration change

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bluetech]

Thanks for investigating this!

[bluetech]

Hmm I learned through this article that we might not need coverage-enable-subprocess anymore. I think I'll try it.

[webknjaz]

@bluetech not sure but I tend to use pytest-cov that definitely doesn't.

[webknjaz]

Thanks for investigating this!

FTR, I'm looking more into this and the change might be incomplete.

[webknjaz]

I made an experimental branch here, in the upstream repo and triggered the workflow from it: https://github.com/pytest-dev/pytest/actions/runs/19276090877/job/55116123406. I cherry-picked this change in there on top of 9.0.x — let's see how it performs before merging.

[webknjaz]

Urgh.. I didn't trigger it the right way. Here's a proper run: https://github.com/pytest-dev/pytest/actions/runs/19276169030/job/55116378101#step:5:406. It does help with the docs diff.
And it also uses the right version in the inner tox invocation (the one running regen): https://github.com/pytest-dev/pytest/actions/runs/19276169030/job/55116378101#step:5:100.

The outer invocation still uses the Git-generated version: https://github.com/pytest-dev/pytest/actions/runs/19276169030/job/55116378101#step:5:24. But that is to be expected — the job itself invoking tox directly doesn't set this var.

[webknjaz]

Oh, it actually updated the existing release PR, proving that this works: https://github.com/pytest-dev/pytest/pull/13928/files#diff-0e43a7f1313ac690564ffafd9a994c5a7faba686ad62c2ea327dab13614dfc8cR23.

[patchback]

Backport to 9.0.x: 💚 backport PR created

✅ Backport PR branch: patchback/backports/9.0.x/ce8b8a7b4b360ac5f3953b8c3b8b59e6bb420f37/pr-13933

Backported as #13935

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.