Use tox for development and consider supporting it

[nathanjmcdougall]

Motivation
At the moment, there is a significant amount of complexity in the codebase just with managing the Bitbucket Pipelines CI. I wonder whether tox is usually overkill for most projects, but it might be the right approach for usethis, because it makes it much easier to switch between CI providers (and makes supporting those providers much simpler). Bitbucket pipelines also has no notion of test matrices so it makes the syntax quite verbose which isn't ideal.

I think it would be good to add tox for development of this project and then see how the setup goes; are there pain points with the existing approach?

Will definitely want to use tox-uv.

Summary of desired enhancement
Consider using tox. Start by adding it for development, and consider the pros and cons for inclusion in usethis itself.

[nathanjmcdougall]

I have done a fair bit of reading on tox and I am still not really understanding what use case it is trying to solve. This blog post definitely has me leaning against it:
https://lukasatkinson.de/2025/just-dont-tox/

I think the conclusions are right that uv plus task runner (which hopefully will be in uv soonish, see #131) serves the main purposes of tox. But I am not entirely sure.

For usethis, the benefits would be if we can reduce duplication between CI configs, but:

• Different CIs have fairly different mechanisms, e.g. bitbucket doesn't support matrices
• People very rarely want to use multiple CIs simultaneously so it's only a benefit to reduce the complexity of usethis itself, not the user
• The current approach is working find so the value added by spending the time on this is probably minimal.

On that basis, and because even now after watching this video and reading the docs, I don't have clarity on the use case for tox, I am going to close this issue for now.