💚 ci: bump build-and-inspect-python-package to v3.0.1 - #207
Merged
nstarman merged 5 commits intoAug 18, 2026
Merged
Conversation
…cs#203) The Distribution build job fails on every PR: Checking dist/quaxed-...-py3-none-any.whl: ERROR InvalidDistribution: Invalid distribution metadata: '2.5' is not a valid metadata version Hatchling now emits Metadata-Version 2.5, which the twine bundled with baipp v2.18.0 is too old to accept. v3.0.1 ships a twine that understands it. Same fix already applied in unxt and galax. The artifact name is unchanged — v3.0.1 uploads `Packages${upload-name-suffix}`, and with no suffix set that is `Packages`, which the test-publish and publish jobs download. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## versions/v0.10.x #207 +/- ##
===================================================
Coverage ? 57.37%
===================================================
Files ? 19
Lines ? 556
Branches ? 0
===================================================
Hits ? 319
Misses ? 237
Partials ? 0 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Two independent breakages from same-day upstream releases. jax 0.11.1 made `PadValueLike` a PEP 695 alias and dropped the `TypeVar` import and `_T` declaration the stub generator anchored `_ArrayValueT` on. Result: `_ArrayValueT` was never declared, and the PEP 695 syntax does not parse under `python_version = "3.11"` — CI failed with `numpy/__init__.pyi: Invalid syntax` on every Python 3.12+ job. Declare `_ArrayValueT` with a privately aliased `_TypeVar`, independent of upstream's imports, and downgrade PEP 695 aliases to an explicit `TypeVar` plus a plain assignment so wheels built on 3.12+ still ship a stub 3.11-targeted type checkers can parse. ml_dtypes 0.6.0 stopped tripping NumPy 2.3's implicit array-to-dtype deprecation, turning the strict xfails on `test_finfo`/`test_iinfo` into XPASS failures. Bisection across jax 0.10.0–0.11.1 x ml_dtypes 0.5.1–0.6.0 confirmed ml_dtypes is the discriminator, not jax; those two tests now gate on numpy >= 2.3 and ml_dtypes < 0.6. `can_cast`, `isdtype` and `dtype` hit the deprecation through NumPy directly and keep the existing marker. Verified: mypy clean on stubs regenerated against both jax 0.10.0 and 0.11.1; full suite green on the newest-deps combination (jax 0.10.2, numpy 2.4.6, ml_dtypes 0.6.0). Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: nstarman <nstarman@users.noreply.github.com>
Backport of the test-only portion of GalacticDynamics#197. Quax's JAX-input dispatch path for these numpy functions was fixed in quax 0.4.x, so `Newest supported deps` (which resolves to current quax regardless of this branch's older floor) started hitting strict-xfail XPASS failures. Drop the stale `xfail_quax58` marks in test_jax.py; the corresponding marks in test_myarray.py stay, since that file covers a separate, still-unfixed MyArray-specific limitation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
My prior removal (2b3d47a) wrongly assumed quax#58 was fixed for every quax this branch supports. The regular CI jobs use this branch's locked quax 0.3.2, where the bug still reproduces (TracerBoolConversionError / ConcretizationTypeError, not the strict-xfail XPASS `Newest supported deps` was hitting) — removing the mark turned those into real failures. Gate the mark on the installed quax version instead, matching the existing NUMPY_VERSION/ML_DTYPES_VERSION conditional-xfail pattern in this file. Verified locally against both the real locked quax 0.3.2 (xfails, 0 failures) and upgraded quax 0.4.3 (no XPASS, 0 failures). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Summary
versions/v0.10.x.hatchling>=1.32.0now defaults toMetadata-Version: 2.5. TheDistribution buildCD check useshynek/build-and-inspect-python-package@v2.17.0, which pinstwine==6.2.0; that version monkeypatchespackaging.metadata._VALID_METADATA_VERSIONSto a stale list that excludes2.5, sotwine checkrejects any wheel built with a recent hatchling.twine==7.0.0(pulled in bybuild-and-inspect-python-package@v3.0.1) drops that stale monkeypatch and natively supports metadata 2.5.numpy/__init__.pyi: Invalid syntaxfailure that 🐛 fix(stubs): support jax 0.11.1 in the numpy stub generator #205 already fixed onmain.stack_pprimitive dispatch forMyArray, gated onJAX_VERSION >= 0.10.1) —Newest supported depswas hitting aNotImplementedErrorfromMyArray.materialise()becausestackhad no MyArray-aware dispatch rule on this branch.xfail_quax58strict-XPASS failuresNewest supported depswas hitting intest_jax.py(quax's JAX-input dispatch path fixed the underlying bug in quax 0.4.0). Unlike main (⬆️ deps: require quax>=0.4.1 #197), which removed the mark outright because main's floor isquax>=0.4.1, this branch keepsquax>=0.3.2as the floor (raising it is out of scope for a patch branch), so the mark is instead gated on the installed quax version (QUAX_VERSION < Version("0.4")) — xfails under this branch's locked quax 0.3.2, doesn't underNewest supported deps's quax 0.4.x. Thexfail_quax58marks intest_myarray.pyare untouched — they cover a separate, still-open MyArray-specific limitation.Test plan
Metadata-Version: 2.5), confirmedtwine==6.2.0failstwine checkon it andtwine==7.0.0passes.uv run --frozen, quax 0.3.2): 0 failures,xfail_quax58xfails as expected.uv run --upgrade-package ..., quax 0.4.3): 0 failures, no XPASS.pre-commit/prekhooks pass on all commits.Distribution buildandNewest supported depsboth pass; verifying the regular Python-version jobs now pass too after fixing an earlier bad assumption (see commit history).