TST: exclude packages newer than a week old from resolution - #19527

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.

Apparently the env var isn't overriding the static config properly. This issue seems specific to tox though, and I was able to confirm that uv behaves correctly on its own.

will report to tox-uv later today or tomorrow.

So, I tried (but failed) to reproduce the problem in a minimal project

pyproject.toml

[project]
name = "test"
version = "0.1.0"
requires-python = ">=3.14"
dependencies = [
    # inifix is a tiny, 0-deps package of mine.
    # 6.1.1 is almost a year old but 6.1.2 was published a couple days ago
    "inifix>=6.1.1",
]

[tool.uv]
exclude-newer = "1 week"

tox.ini

[tox]
envlist =
    py314,-pre
requires =
    tox-uv

[testenv]
setenv =
    pre: UV_EXCLUDE_NEWER = 0day # allow latest versions with no cooldown period. Also a security pun.
commands =
    {list_dependencies_command}

abridged logs

❯ tox -e py314-pre             
(...)
py314-pre: commands[0]> .tox/.tox/bin/uv --color never pip freeze
Using Python 3.14.3 environment at: .tox/py314-pre
inifix==6.1.2
test @ file:///private/tmp/test/.tox/.tmp/package/1/test-0.1.0.tar.gz
  py314-pre: OK (2.32=setup[2.31]+cmd[0.01] seconds)
  congratulations :) (2.34 seconds)

I got inifix 6.1.2, proving that everything is behaving as I'd expect. This means that the issue I ran into only shows up in a more complex scenario, and might still be a bug in uv. I'll try to refine this later.

some progress on this: it looks like tox isn't invalidating its own cache on edits to tox.ini (at least not all of them. I'll still assume it behaves as expected if I change deps, extras or dependency_groups settings). Now the question becomes: are we caching tox envs in CI ?

yes we are: #18835 (I forgot the specifics of this PR)

except... that's not the whole story yet. The failing job is running on Circle CI, whose config wasn't updated in #18835

... and I don't think we're caching any dependency on this service.
To be specific, we're not using save_cache

(still, I reported tox-dev/tox#3917 to clear the air)

Keeping an eye out for astral-sh/uv#18839

This is working as expected now. I would have prefered defining a global exclude-newer in [tool.uv] and overriding it with anv env var in select tox envs but this approach didn't work so this will do for now

If we ignore the cooldown for devdeps anyway, what are we really guarding against here?

Malicious releases installing on any other job.

But if it is malicious and already have access to devdeps job, does it matter?

It's still incremental progress. I can tighten the screw some more later on by defining a whitelist of trusted packages (numpy, scipy, matplotlib ...) that we actually want to use nightlies of, which will remove the risk from other (direct or otherwise) dependencies.

tighten the screw some more later

Should that be part of this PR?

There is an "upstream action required" label. Is this blocked by something else?

Should that be part of this PR?

My hope was to get this one merged quickly so we'd get half the benefit immediately. As it stands I would still prefer to defer the fine tuning to a follow PR.

There is an "upstream action required" label. Is this blocked by something else?

Sorry for dropping the ball here. I should have linked to my upstream report:
tox-dev/tox#3917
It's actually been fixed in tox-uv 1.35

Given @nstarman's approval and since there's nothing blocking now, I'll merge this and will open a follow up PR to tentatively refine tuning on devdeps.

follow up: while there are options to create a white list of packages as I suggested earlier, I think I'm seeing a better solution and proposed it upstream astral-sh/uv#19749

turns out the feature I proposed already exists: 🤦🏻‍♂️ + 🎉

the follow up PR is at #19886