Fix CI: pin Python to 3.13 to match Pipfile.lock - #179
Merged
Conversation
The PyTest workflow requests python-version: "3.x", which now resolves to CPython 3.14. Pipfile.lock pins scipy==1.15.3, whose newest wheels are cp313, so pip falls back to building scipy from its sdist. That build needs OpenBLAS, which ubuntu-latest does not provide, and 'make setup-dev' fails before any test runs. Pinning to 3.13 is the newest interpreter the current lockfile resolves against: scipy, numpy, pandas and shapely all publish cp313 manylinux wheels, and the one sdist-only dependency (turfpy 0.0.7) is pure Python. The publish workflow runs the same pipenv install against the same lockfile, so it is pinned identically.
Merged
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
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.
The PyTest workflow currently fails on every PR, before any test runs.
Cause
pytest.ymlrequestspython-version: "3.x", which resolves to whatever the newest CPython on the runner is — today 3.14.7.Pipfile.lockpinsscipy==1.15.3, and that release publishes wheels only up tocp313. With no matching wheel, pip falls back to building scipy from its sdist, which needs BLAS:ubuntu-latesthas no OpenBLAS, so the build dies andmake setup-devexits non-zero:(
scipyis not a direct dependency — it arrives transitively viaturfpy.)This is time-based rot rather than a regression from any one commit: the last green run of this workflow on
mainwas 2025-07-21. Python advanced to 3.14 while the lockfile stayed frozen, so the unpinned"3.x"drifted off the end of what the lockfile can resolve.Fix
Pin
python-versionto"3.13"— the newest interpreter the current lockfile resolves against. I checked all 73 locked packages against PyPI: every one either ships a universal wheel or acp313manylinux wheel, and the single sdist-only dependency (turfpy==0.0.7) is pure Python with no build requirements.pypi-publish.ymlruns the samepipenv install --devagainst the same lockfile and carries the same"3.x", so it is pinned identically — otherwise the next push tomainwould fail the same way at publish time.Alternative considered
Regenerating
Pipfile.lockfor 3.14 would also work and would let CI track"3.x"again, but it is a dependency refresh across 73 packages and a much larger change to review. The pin restores the signal with a two-line change; refreshing the lockfile is worth doing separately and deliberately.Notes
Out of scope, but noticed nearby and worth a follow-up:
main-docs.ymldeclarespython-version: [3.6]in a matrix that is never consumed — the job only runs yarn/npm, so the value is a no-op leftover.pypi-publish.ymlsetsenvironment.urltohttps://pypi.org/p/notehub-py, which looks copy-pasted from another project.Test plan
CI on this PR is the test: the
buildjob should now get throughInstall dependenciesand run black, flake8 and pytest.