"plan/py314 phase-5: CI matrix (3.10-3.14) + modernize publish#215
Conversation
Add .github/workflows/test.yml: uv-based matrix running the suite on Python 3.10-3.14 on push to master and on PRs (free on public repo, no secrets). Sets MP_CONTEXT_TYPE=fork and dummy AWS creds for moto. Modernize python-publish.yml: build with 'uv build' instead of the removed 'python setup.py sdist', drop the dead dockerizer two-pass (the referenced disdat/infrastructure/dockerizer path no longer exists), upload via 'uvx twine', and bump actions/checkout + setup to current majors (setup-uv). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6dd97d1304
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Install uv | ||
| uses: astral-sh/setup-uv@v5 | ||
| with: | ||
| python-version: '3.x' |
There was a problem hiding this comment.
For release/manual publish runs, astral-sh/setup-uv@v5 treats python-version as the value for UV_PYTHON rather than as the actions/setup-python alias syntax (see its action metadata: https://raw.githubusercontent.com/astral-sh/setup-uv/v5/action.yml). With this set to 3.x, the following uv build resolves Python as an executable named 3.x and fails before producing dist/*; remove this input or use an exact supported version such as 3.13.
Useful? React with 👍 / 👎.
| python-version: ${{ matrix.python-version }} | ||
|
|
||
| - name: Install project and dev dependencies | ||
| run: uv pip install --system -e ".[dev]" |
There was a problem hiding this comment.
In this matrix workflow, setup-uv sets UV_PYTHON, but this --system install plus the later bare python -m pytest does not guarantee that dependencies are installed into, and tests are executed by, the same matrix interpreter; uv's GitHub Actions guidance installs with uv sync and runs commands with uv run for the selected Python (https://docs.astral.sh/uv/guides/integration/github/). On rows where ${{ matrix.python-version }} differs from the runner default, CI can either fail with missing packages or silently test the default Python instead of 3.10/3.11/3.13/3.14.
Useful? React with 👍 / 👎.
uv pip install --system fails on setup-uv's externally-managed interpreter (PEP 668: 'The interpreter ... is externally managed'). Create a uv venv and install/run there instead, matching CONTRIBUTING.md and local usage. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c745bf4eca
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - name: Install uv | ||
| uses: astral-sh/setup-uv@v5 | ||
| with: | ||
| python-version: '3.x' |
There was a problem hiding this comment.
On release/manual publish runs, setup-uv@v5 treats python-version as the value for UV_PYTHON (and creates/activates that environment), and uv build --help shows the build interpreter comes from --python ... [env: UV_PYTHON]. The value 3.x is setup-python-style syntax rather than a valid uv interpreter request (uv python find 3.x looks for an executable named 3.x and fails), so the publish workflow will fail before uploading; omit this input or use a concrete version like 3.14.
Useful? React with 👍 / 👎.
…dex review) test.yml: setup-uv@v5 with python-version already creates+activates .venv, so a bare 'uv venv' failed with "already exists". Use 'uv venv --clear' so the matrix interpreter venv is (re)created deterministically; tests run via .venv/bin/python, pinned to the matrix version. python-publish.yml: setup-uv maps python-version to UV_PYTHON, so '3.x' made 'uv build' look for an interpreter literally named 3.x and fail (Codex P1). Use a concrete '3.13'. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The suite assumed a pre-existing ~/.config/disdat (created once via 'dsdt init'); it passed locally only because developer homes already have it. On a fresh CI runner the config is absent, so every test errored at setup with "Did not find Disdat configuration". Add a session-scoped autouse fixture (tests/conftest.py) that runs DisdatConfig.init() when the config dir is absent. Guarded on existence because init() exits the process if the dir already exists, so existing developer configs are left untouched. Makes 'pytest tests' self-contained for CI and fresh clones. Verified: full suite passes with a fresh HOME (simulating CI); existing config left unmodified. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Split the publish workflow into two event-gated jobs: - publish-pypi (release): build from the release tag (clean version), twine check, upload to PyPI. - testpypi-dry-run (workflow_dispatch): build a dev version, twine check, upload to TestPyPI with --skip-existing. Real PyPI is never touched on a manual run. Manual dispatch previously would have tried to publish a dev build with a setuptools_scm local segment (+gHASH) that PyPI rejects. The dry-run job strips the local segment via SETUPTOOLS_SCM_OVERRIDES_FOR_DISDAT so the dev build is valid for TestPyPI. Also add `twine check` to both paths. Requires a TEST_PYPI_API_TOKEN repository secret for the dry-run upload. Verified locally: release build -> clean 1.1.5, dispatch build -> 1.1.5.dev8; twine check passes and both wheel+sdist install in a clean venv. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
Final phase of design_docs/plans/py-3.10-3.14-migration.plan.md