Conversation
| requires = | ||
| tox>=4.51.0 | ||
| tox-uv | ||
| tox-uv-bare |
There was a problem hiding this comment.
Wait, what? Is it published under two names now? 🤔
There was a problem hiding this comment.
Bare doesn’t install uv as a dependency
| @@ -3,7 +3,7 @@ | |||
| [tox] | |||
| requires = | |||
There was a problem hiding this comment.
This looks like a use case for having tox to implement referencing this section from dep groups to dedupe the list..
cc @gaborbernat
There was a problem hiding this comment.
In this case it’s more of a belts-and-suspenders thing since we always run tox using uv. Maybe should be removed to fail loudly? Idk
There was a problem hiding this comment.
Well, my understanding is that this is for people that have tox as a primary pre-existing entry-point (and not uv) — tox then makes a managed venv under .tox/.tox/ and installs all the goodies + a newer version of itself. So to me this sounds like a more logical hook point for sticking automatic provisioning. I'm wondering, though, if tox's API allows plugins to extend this list — this would make for a powerful mechanism of setting up centralized ecosystem-centric infras.
I think this might also be in use by downstreams. But we'd have to ask @hroncok @befeleme @encukou @mgorny etc.
There was a problem hiding this comment.
The Fedora use case is verifying if things work in a given pre-existing environment (without PyPI wheels & without internet access). tox doesn't make a venv; instead a plugin checks if dependencies are installed. If any are missing it reports them, and gets re-run in a container that includes them.
For that, it doesn't really matter if uv gets installed, as long as it doesn't try downloading/provisioning anything :)
Anyway, removing tox.requires seems OK.
3 participants
Better reproducibility everywhere.