tox -e test-devdeps behaviour depends on uv cache

@neutrinoceros

Description

While doing #20262, which was aiming to fix an error with devdeps, I found that locally using tox -e test-devdeps, I got errors because the numpy-dev version was not updated to the most recent nightly version. I ended up realizing an older version was used that was still in the cache of uv; after I removed it (rm ~/.cache/uv/wheels-v6/index/8c88d1ad25681004/numpy), things worked as expected.

But obviously, this should not be necessary. Is there an incantation that we can put in tox.ini that ensures uv properly checks whether a new version is available?

Ping @neutrinoceros as our local uv expert...

p.s. Presumably, this does not hit CI since there the cache is always clean. Which, as an aside, means one is constantly downloading the same things. Sigh.

Presumably, this does not hit CI since there the cache is always clean.

not sure about that. We're supposed to cache pypi packages in CI too, though I'd need to check how everything fits together between uv, tox, tox-uv, OpenAstronomy/github-actions-workflows and actions/setup-python ...

Overall, there may be several small issues compounding badly here:

numpy's version doesn't change along a dev branch, so resolvers (uv) cannot easily invalidate their caches
tox manages its own cache, supposedly as an extra layer on top of uv's
tox-uv isn't always accurate in how it decides to invalidate tox's cache

One way we could workaround it on our side would be to disable caching for the devdeps factor. The quick-and-dirty approach would be

diff --git a/tox.ini b/tox.ini
index 187fb0c82c..c8b01f673b 100644
--- a/tox.ini
+++ b/tox.ini
@@ -31,6 +31,7 @@ setenv =
     mpldev: UV_INDEX = https://pypi.anaconda.org/scientific-python-nightly-wheels/simple
     !devdeps-!mpldev-!predeps-!devpytest: UV_EXCLUDE_NEWER = P7D
     devdeps, mpldev, predeps, devpytest: UV_INDEX_STRATEGY = unsafe-best-match # match pip's behavior
+    devdeps, mpldev: UV_NO_CACHE = 1
     fitsio: ASTROPY_ALWAYS_TEST_FITSIO = true
     # on oldestdeps, we let warnings be warnings (-Wdefault) instead of treated-as-errors,
     # so we don't need to deal with filtering anything triggered from dependencies

But we could also disable it at the index level using
https://docs.astral.sh/uv/concepts/indexes/#customizing-cache-control-headers
which would nicely fit into #19886, but could also be done as a follow up, closing this issue ?

Ah, yes, I feared that the problem at some level was the nightlies having no explicit version. Given that, the idea of doing it as a follow-up to #19886 specifically targeting that index seems reasonable. Though perhaps scientific python should start having version numbers? Shall we raise an issue there?

Though perhaps scientific python should start having version numbers? Shall we raise an issue there?

I don't know that it's possible to do it at a policy level but maybe it could be a simple recommendation so yeah. Do you know where to report it (I don't) ?

@bsipocz

@bsipocz, @astrofrog - I think you are a bit more involved in nightlies produced by scientific python. As is, these do not have version numbers, which means they do not automatically get updated if one has one in cache (at least not by uv, presumably not by pip either). Would you know who to contact about whether it might be possible to change that? (I guess the alternative would be to always download from those, which is not unreaonable, but it means it would be trickier to set up.)

these do not have version numbers

to be clear, this is a problem for some packages, including numpy and h5py, but not all; scipy, pandas, matplotlib or astropy itself all have evolving dev versions.

these do not have version numbers

to be clear, this is a problem for some packages, including numpy and h5py, but not all; scipy, pandas, matplotlib or astropy itself all have evolving dev versions.

Hmm, maybe it would be numpy and h5py that I'd need to ping, then...

(FYI I'm probably the person you'll end up discussing with for h5py :D)

Navigation Menu

Repository navigation

tox -e test-devdeps behaviour depends on uv cache #20263

Description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

tox -e test-devdeps behaviour depends on uv cache #20263

Description

Description

Activity

neutrinoceros commented on Aug 23, 2026

mhvk commented on Aug 23, 2026

neutrinoceros commented on Aug 24, 2026

mhvk commented on Aug 24, 2026

neutrinoceros commented on Aug 24, 2026

mhvk commented on Aug 24, 2026

neutrinoceros commented on Aug 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions