You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: alldeps pulls in too many "optional" packages and there could be pinning conflicts with oldestdeps, causing unwanted version bumps. Example at #16903 (comment)
This combo was introduced in #12522 (comment) . It was a while ago when we did not have so many "optional" dependencies and that PR was to simplify jobs, so this combo was not necessarily to fix some specific problem we had per se.
Proposal: Remove alldeps from oldestdeps. Any "optional" dependencies we want to test there should be explicitly pinned in tox.ini instead. There are already 3 other jobs in regular CI alone that pulls in alldeps anyway, so I don't see the need to test alldeps against our oldestdeps.
Note that another solution would be to add a calendar-based constraint on the env resolution strategy. This would effectively set an upper limit on every package installed in oldestdeps, avoiding the kind of mess we saw earlier where some of our direct deps are pinned but nothing else is.
This is trivial with uv, e.g. uv pip install --exclude-newer '2022-08-14' (picking numpy 1.23.2's release date for example), but it would require tox-uv.
I'm making progress but not quite ready for a PR yet (maybe later today though). Just wanted to report back at this stage:
--exclude-newer seems like a dead end because in some cases, we might be requiring dev dependencies (e.g. pytest-astropy) more recent than our oldest-supported version of, say, numpy
--resolution=lowest-direct is much more promising but it doesn't play nicely with deps specified without a lower bound (it will try to install the oldest version of them all, which is, as you might guess, completely broken for us). Basically this strat forces me to give lower bounds to every dependency, which means more concrete information in project metadata (good for future proofing, but also takes a bit of time).
over yesterday's telecon, we said we wanted to restrict the use of uv to oldestdeps for now, but in practice, I'm finding it's actually simpler to use tox-uv everywhere (I'm guessing that's why this plugin exists). I'll still follow the plan we discussed but I'll highlight the additional complexity in my PR.
See #16960 for step 0. I'll open a pair of (mutually exclusive) PRs to implement "oldestdeps with uv's --resolution=lowest-direct" as soon as possible, but not tonight (I'm running late).
I forgot to reply here: I'd rather give tox+uv a chance as I think it is a much more general solution and other than the upfront cost of tiding up our existing tox.ini to enable it, I have not found any problems with it at this point.
Activity
neutrinoceros commentedon Sep 5, 2024
Note that another solution would be to add a calendar-based constraint on the env resolution strategy. This would effectively set an upper limit on every package installed in
oldestdeps, avoiding the kind of mess we saw earlier where some of our direct deps are pinned but nothing else is.This is trivial with
uv, e.g.uv pip install --exclude-newer '2022-08-14'(picking numpy1.23.2's release date for example), but it would requiretox-uv.pllim commentedon Sep 5, 2024
I would certainly be interested to see a draft PR with the
uvroute. Thanks! 😉neutrinoceros commentedon Sep 6, 2024
I'm making progress but not quite ready for a PR yet (maybe later today though). Just wanted to report back at this stage:
--exclude-newerseems like a dead end because in some cases, we might be requiring dev dependencies (e.g.pytest-astropy) more recent than our oldest-supported version of, say, numpy--resolution=lowest-directis much more promising but it doesn't play nicely with deps specified without a lower bound (it will try to install the oldest version of them all, which is, as you might guess, completely broken for us). Basically this strat forces me to give lower bounds to every dependency, which means more concrete information in project metadata (good for future proofing, but also takes a bit of time).oldestdepsfor now, but in practice, I'm finding it's actually simpler to use tox-uv everywhere (I'm guessing that's why this plugin exists). I'll still follow the plan we discussed but I'll highlight the additional complexity in my PR.neutrinoceros commentedon Sep 6, 2024
See #16960 for step 0. I'll open a pair of (mutually exclusive) PRs to implement "oldestdeps with uv's
--resolution=lowest-direct" as soon as possible, but not tonight (I'm running late).pllim commentedon Sep 6, 2024
Oh yeah, what about https://github.com/OpenAstronomy/minimum_dependencies instead of
uv? I forgot this moved upstream from William's account because @Cadair wanted it too.neutrinoceros commentedon Sep 10, 2024
I forgot to reply here: I'd rather give tox+uv a chance as I think it is a much more general solution and other than the upfront cost of tiding up our existing
tox.inito enable it, I have not found any problems with it at this point.