Proposed new feature or change:
The problem
Almost every dependency in pyproject.toml is unconstrained, so pip is free to install very old versions alongside uxarray. Some of those combinations don't work, and users only find out at runtime.
Here is an install that pip accepts today without complaint:
pip install "uxarray[geo]" healpix==2023.4 spatialpandas==0.4.9 antimeridian==0.2.6
All three packages are too old to work with current uxarray. antimeridian doesn't accept an argument we pass it, and spatialpandas and healpix are each missing a function we call. Nothing catches this at install time, and when it does fail the error points at the dependency rather than at the real problem, which is the install itself.
Those three are just the ones I happened to find. Since nothing declares a floor, the same thing can happen with any dependency, and it gets more likely as the ecosystem moves on.
Why the CI part matters as much as the version numbers
Adding minimums to pyproject.toml is the easy half. Keeping them honest is the hard half. CI currently builds ci/environment.yml, which is unpinned, so every run tests the newest build of everything. Any minimum we write down would be a guess that nobody ever checks, and it would quietly drift out of date.
The fix is a second environment file that pins every dependency to its declared minimum, plus a CI job that runs the test suite against it. Then the bounds are something we actually verify, and if one goes stale we hear it from CI instead of from a user.
What I have already
I put together a branch that does both: https://github.com/xylar/uxarray/tree/add-dependency-constraints
It adds a lower bound for every dependency, each with a short comment saying what sets it. Most follow SPEC 0, the scientific Python convention of supporting roughly the last two years of releases. A handful are higher because uxarray uses something that genuinely didn't exist before then.
It also adds ci/environment-min.yml, which pins each of those minimums. The full test suite passes against it — 963 passed, 1 skipped, the same result as with the latest of everything — so the bounds aren't guesses. The piece it doesn't do yet is wire that environment into CI, which I'd add if there's interest.
I left the matplotlib<3.11 cap alone, since there's already work in flight that replaces it with a cartopy floor instead.
Question
Is this something the team would welcome? If so I'm happy to open a PR. And if you'd rather go a different direction — a stricter or looser policy than SPEC 0, or the bounds without the CI job — I'm glad to adjust.
Drafted by Claude Code and @xylar together
Proposed new feature or change:
The problem
Almost every dependency in
pyproject.tomlis unconstrained, so pip is free to install very old versions alongside uxarray. Some of those combinations don't work, and users only find out at runtime.Here is an install that pip accepts today without complaint:
All three packages are too old to work with current uxarray.
antimeridiandoesn't accept an argument we pass it, andspatialpandasandhealpixare each missing a function we call. Nothing catches this at install time, and when it does fail the error points at the dependency rather than at the real problem, which is the install itself.Those three are just the ones I happened to find. Since nothing declares a floor, the same thing can happen with any dependency, and it gets more likely as the ecosystem moves on.
Why the CI part matters as much as the version numbers
Adding minimums to
pyproject.tomlis the easy half. Keeping them honest is the hard half. CI currently buildsci/environment.yml, which is unpinned, so every run tests the newest build of everything. Any minimum we write down would be a guess that nobody ever checks, and it would quietly drift out of date.The fix is a second environment file that pins every dependency to its declared minimum, plus a CI job that runs the test suite against it. Then the bounds are something we actually verify, and if one goes stale we hear it from CI instead of from a user.
What I have already
I put together a branch that does both: https://github.com/xylar/uxarray/tree/add-dependency-constraints
It adds a lower bound for every dependency, each with a short comment saying what sets it. Most follow SPEC 0, the scientific Python convention of supporting roughly the last two years of releases. A handful are higher because uxarray uses something that genuinely didn't exist before then.
It also adds
ci/environment-min.yml, which pins each of those minimums. The full test suite passes against it — 963 passed, 1 skipped, the same result as with the latest of everything — so the bounds aren't guesses. The piece it doesn't do yet is wire that environment into CI, which I'd add if there's interest.I left the
matplotlib<3.11cap alone, since there's already work in flight that replaces it with acartopyfloor instead.Question
Is this something the team would welcome? If so I'm happy to open a PR. And if you'd rather go a different direction — a stricter or looser policy than SPEC 0, or the bounds without the CI job — I'm glad to adjust.
Drafted by Claude Code and @xylar together