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.

One suggestion: if we think regular tox should continue to work (which seems a good idea to me), we should have at least some runs in CI that use it, i.e., omit the toxdeps: tox-uv in some/most cases.

Yes, that was the initial plan, and I amended it because there were some hard-coded pip calls in tox.ini so it felt unescepable to hard wire uv instead, but that's not the case anymore after #16973 and #16975, so I can revert a bunch of changes here and use tox-uv only when it's needed.

Also, if things will not work for oldestdeps, the help line for that should mention it.

good call.

Aside, I assume that something like oldestdeps: tox-uv in tox.ini is not going to be good enough, right? It would come too late, presumably.

yeah unfortunately it doesn't work (already tried). I also made an attempt at implementing a way to crash oldestdeps runs early if tox-uv wasn't available at runtime but I didn't find a reliable way to do that. So I guess for now I'll stick to your suggestion of better documenting it.

p.s. Things like pip freeze, which is done inside tox.ini, are OK with uv?

That was the point of #16973 and #16975: tox has native substitution mechanisms and tox-uv brings the necessary changes behind the curtain. In particular it changes the default install_command from python -I -m pip install to uv pip install and changes list_dependencies_command from pip freeze --all to uv pip freeze.

rebased following #17675

Indeed the bump is causing a regression. Reported as #17681
Switching this PR to draft in the mean time.

rebased to fix a conflict with #17711

This is back to a stable state. Anyone up to bite the bullet ?

I think it is time we make a decision.

• Pro: tox-uv will test oldestdeps with really the minversions we claim in pyproject.toml
• Con: tox-uv becomes a dependency of any tox run, not just oldestdeps and some env var names have to be changed to UV stuff.

I see there are already 2 approvals. Should we merge soon or are there some remaining concerns that would be blockers?

I will also point out that "use uv or not have one source of truth" isn't strictly a fair comparison as minimum_dependencies exists and works well without using uv.

Fair point. Although this tool doesn't work out of the box for this case¹, we can always fix it and switch if we encounter issues with uv/tox-uv.

1. it doesn't seem to understand self-referential requirements like astropy[test_all] -> astropy[all]

Yes this is a pain (OpenAstronomy/minimum_dependencies#30) but it's not the end of the world to list all the extras.

but it's not the end of the world to list all the extras.

sure, but then you're back to not having a single source of truth 🙃

sure, but then you're back to not having a single source of truth 🙃

Well you have a source of truth for the deps, if not all the extras. 🤷 It's a bug which should be fixed, but it's in the deps parsing code in some other library and is generally hard to unravel.

I am officially bored of this conversation.

Would this still work?

@mhvk Thanks for pointing this out, I honestly had no idea that someone would use tox to create virtualenvs. The answer is a yes but: uv does not include pip itself in virtualenvs it creates (because it makes it redundant), so if you were to run the exact commands you showed in that order, you'd get stopped at

$ pip install ipython
/Users/clm/dev/astropy-project/coordinated/astropy/.tox/test/bin/python: No module named pip

but that's trivially solved by either:

* typing `uv pip` instead of `pip`

* running the awkward (but functional) command `uv pip install pip` between env activation and any further install

is this satisfactory ?

@neutrinoceros - now that this PR is merged, I noticed that my workflow of

tox -e test --develop --notest
pip install ipython

is indeed broken (as expected). However, your statement that I could just do uv pip install ipython turns out not to be true, since by default uv is not in the path, so I'm stuck with .tox/.tox/bin/uv pip install ipython, which is quite long. There probably is a clever trick to have this work, but I haven't been able to find it. Any suggestions?

I am sure others might run into the same problem, so let's move follow-up discussions to the issue below. Thanks!

• TST: Hard to install ipython into local test run with tox-uv #17793