TST: fine tune per-index cooldown periods - #19886

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

Ah, this doesn't quite work as I thought. Configuring an index implies it's always included in resolution, which isn't what we want.

This is now working as intended, with an extremely minor defect: it h5py's nightlies are currently preferred to stable releases. And that's just because it doesn't use dev version numbers (yet). All other nightly packages behave as you'd expect, so even with indexes permanently configured, we only get nightlies when preleases are enabled.

h5py is now in line with other nightly-publishers, so there really nothing blocking this anymore !

beyond the cleanup aspect, it would useful for me (and other uv users) to get this in. It makes installing devdeps much easier from calling uv directly (--pre is then sufficient to tap into nightly builds, which is generally what I want)

With the release of uv 0.12.0 this also simplifies testing CPython pre-prereleases, because e.g. numpy nightlies will be auto selected when no other binary is available.

@astrofrog could we get this in soon ?

@Andrej730, as a uv user, can I ask you for a review ?

No idea how much any of the below is practically possible to be harmful, just tried to think through the edge cases of such change.

Having --pre being useful directly at uv seems convenient indeed, but unfortunately there's no way in uv to cleanly configure it to use some indexes only on --pre. Ideally, uv needs some kind of flag in tool.uv.index to mark index to be considered only during --pre. But in its absence, all indexes will be used always and there are some drawbacks.

As you mentioned, h5py is posting their release wheels to the nightly too (e.g. h5py-3.16.0-cp311-cp311-win_arm64.whl currently available at https://pypi.anaconda.org/scientific-python-nightly-wheels/simple/h5py/ and https://pypi.org/project/h5py/#files), so when I do uv sync currently it picks up https://pypi.org/simple and after this PR it will pick up anaconda.

(you mentioned it as fixed, but apparently it's either regressed and starting posting non-dev builds again or I misunderstood your message)

So there's a bit of risk involved because non-pre users start to depend on how well nightlies are maintained.
It brings us to 2 possible problems:

• current releases on nightlies shadowing pypi releases - as it is with h5py. In most cases it's probably not a problem - it's likely that releases on nightlies are exact releases from pypi, but there's strictly speaking there's no guarantee. They also can possible sneak into lock files, if they will be ever adapted.

Had an idea that it can be worked around just by adding pypi index to the toml explicitly, that will make it first choice instead of being a default index (which in uv means a fallback) and will guard from duplicated releases from nightlies.

[[tool.uv.index]]
name = "PyPI"
url = "https://pypi.org/simple"

• second case is if nightly all of a sudden will have h5py-3.17.0 release while it's still not present on the PyPI. Having exclude-newer = "P7D" guarding against the most severe cases when something truly breaking sneaks in, but it may be unexpected in some cases.

One more thing to note that currently it will be checking all packages from nightly indexes. Unsure if some unexpected package might show up, but maybe its worth using explicit = true for those indexes - at least to document what packages are expected to get nightlies if --pre is used.

Thanks a bunch !

(you mentioned it as fixed, but apparently it's either regressed and starting posting non-dev builds again or I misunderstood your message)

Thanks for pointing it out. I was assuming the old wheels would be gone by now but they're not. Fortunately I have the key to this index and should be able to delete them manually :)

They also can possibly sneak into lock files

uv.lock is invalidated if one changes the prerelease setting, so I don't think that's correct

Had an idea that it can be worked around just by adding pypi index to the toml explicitly, that will make it first choice instead of being a default index (which in uv means a fallback) and will guard from duplicated releases from nightlies.

Interesting ! is that still true with index-strategy="unsafe-best-match" ?

One more thing to note that currently it will be checking all packages from nightly indexes. Unsure if some unexpected package might show up, but maybe its worth using explicit = true for those indexes - at least to document what packages are expected to get nightlies if --pre is used.

I'll need to look into it !

Fortunately I have the key to this index and should be able to delete them manually :)

update: I just did

One more thing to note that currently it will be checking all packages from nightly indexes. Unsure if some unexpected package might show up, but maybe its worth using explicit = true for those indexes - at least to document what packages are expected to get nightlies if --pre is used.

If I'm understanding the docs correctly, this would actually completely disable nightly indexes until uv add is used to set [tool.uv.sources], which seems like a step back in terms of practicality: it won't compose nicely with tox or direct uv users. Am I missing something ?

ref: https://docs.astral.sh/uv/concepts/indexes/#pinning-a-package-to-an-index

They also can possibly sneak into lock files

uv.lock is invalidated if one changes the prerelease setting, so I don't think that's correct

To clarify - I meant e.g. if h5py 3.16 release is present on both PyPI and nightly, then it might get locked using nightly url and then nightly url might become dead and there will be an error during resync.

Had an idea that it can be worked around just by adding pypi index to the toml explicitly,

Interesting ! is that still true with index-strategy="unsafe-best-match" ?

Yeah, can confirm it, I was testing with this PR + explicit PyPI index and it was preferring h5py from PyPI. I believe if the best matching version is present on the multiple indexes, it just picks the first one from the list.

If I'm understanding the docs correctly, this would actually completely disable nightly indexes until uv add is used to set [tool.uv.sources], which seems like a step back in terms of practicality: it won't compose nicely with tox or direct uv users. Am I missing something ?

Ahh, you're right, I thought it's possible to do h5py = { index = ["sp-nightlies", "PyPI" } in tool.uv.sources and then sp-nightlies would only be considered for h5py. But uv only allows h5py = { index = "sp-nightlies" }, locking everyone to nightlies, so explicit = true is not an option.

Fortunately I have the key to this index and should be able to delete them manually :)

update: I just did

A bit harder to reproduce nightly index sneaking in now, haha.

To clarify - I meant e.g. if h5py 3.16 release is present on both PyPI and nightly, then it might get locked using nightly url and then nightly url might become dead and there will be an error during resync.

Oh, that's right. Fortunately h5py was the only rogue package in the entire index and the easiest one to fix for me, but I am explicitly assuming that this won't happen again, and if it does... well, lock files are human-readable and I hope we'll be collectively disciplined enough to leverage this feature and not commit such a change.

Since @jdavies-st just stared into this UV rabbit hole elsewhere, I would appreciate extra pair of eyes if he has the time. Thanks, all!

rebased, now explicitly opting in the index-exclude-newer preview feature, disabling the warning that normally comes along with it.

@astrofrog I think all your requests were addressed. Let me know if there's anything else !