Skip to content

Add minimum versions for dependencies, and CI that tests them #1781

Description

@xylar

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

CIContinuous IntegrationdependenciesPull requests that update a dependency filenew featureNew user-facing functionality

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions