chore: Use tox-uv and uv.lock to test minimum, locked, and pre-release dependencies

[effigies]

My goal is to remove dependency caps, which lead to very fragile environment resolutions. I understand that the purpose of these caps is to ensure that regressions can be localized to changes in specific dependencies, so this PR uses uv lockfiles to address that.

uv lock [--upgrade] inspects PyPI and finds the latest versions of tools that successfully satisfy the environment described by pyproject.toml, including optional dependencies. You can checkout the repository and get the same environment as anybody else with uv sync.

This PR also uses tox-uv to create environments py<ver>-{min,latest,pre}. py*-min attempts to install the minimum versions that are declared in pyproject.toml into an environment that created with the declared Python version. py*-latest will use uv sync to setup the environment, while py*-pre will look for pre-release versions of dependencies, so that you can catch breakages coming down the line.

It also sets the dependabot environment to uv, to auto-update your uv.lock file, and sets up a GitHub action to run tox, as a demonstration. If this looks like a good approach, I'll figure out how to replace your conda environments in CircleCI with uv sync-based ones.

Addresses #1185.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.86%. Comparing base (b7622fa) to head (8084587).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1229      +/-   ##
==========================================
- Coverage   89.90%   89.86%   -0.04%     
==========================================
  Files          29       29              
  Lines        4379     4383       +4     
  Branches      725      725              
==========================================
+ Hits         3937     3939       +2     
- Misses        293      295       +2     
  Partials      149      149              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eurunuela]

This is great stuff Chris, thank you! My only question is, moving forward, is there anything that we (devs) have to change in our setups?

We also tried to use Python version matrices in our CircleCI but had issues with conda. Do you think this approach would make it easier to implement this idea we had to abandon?

[effigies]

I think you shouldn't need to change anything. Do you want to show me what you tried with the version matrices, and I can see if it'll be any easier now?

[eurunuela]

You can see the changes we reverted in #1202. We thought the matrices were going to work fine but ended up having to go back to the current configuration.

[effigies]

I see. Not sure I've got it in me to play with a new workflow syntax. But I'll see if I can use uv instead of conda, at least.

Test failures seem to be related to an OSF error causing 403 responses.

[eurunuela]

Test failures seem to be related to an OSF error causing 403 responses.

We've had these before. We usually just rerun the ones that failed.

[effigies]

Okay, I've updated CircleCI. I think this is more-or-less usable right now, but I realize that introducing new maintenance tools is a bit like giving someone a hot potato, so I'm happy to jump on a call to talk this over with people. At the very least, hopefully this is a demo of an overall approach, and you can adapt it to suit your needs. I won't be offended if you close this PR.

[eurunuela]

I think the easiest would be that you join our next devs meeting on June 19th. Unless it conflicts with OHBM.

[effigies]

I should be around then. I'm not going to make it to OHBM this year.

[tsalo]

Since this has been sitting for a while and it should improve things for dependent tools like AFNI and fMRIPrep, I think we should just move forward with this- i.e., address the conflicts and merge. It doesn't sound like it should impact our maintenance activities, and if something comes up we can always ask @effigies. @handwerkerd, @eurunuela WDYT?

[effigies]

Looks like nilearn/nilearn#5585 broke things here and in mapca, so had to put in a pin.

[eurunuela]

Since this has been sitting for a while and it should improve things for dependent tools like AFNI and fMRIPrep, I think we should just move forward with this- i.e., address the conflicts and merge. It doesn't sound like it should impact our maintenance activities, and if something comes up we can always ask @effigies. @handwerkerd, @eurunuela WDYT?

Sounds good to me!

[tsalo]

LGTM, thank you!

[handwerkerd]

I'm running this locally and some tests are failing in my python=3.13 and make lint is failing (some interaction with black) in my python=3.11 environment. I'm looking into this a bit more to see if it's a problem on my end, but I wanted to put a comment here.

As for the PR in general, one thing that confuses me about the change, is if there's anything developers would need to do differently to interact with the code. If so, that information should be added to here: https://github.com/ME-ICA/tedana/blob/main/CONTRIBUTING.md

[effigies]

My goal here was strictly to allow CI to better stick to capped dependencies without having to put them in pyproject.toml. Nothing you have should stop working, but you can definitely lean into tox and uv more. I'll update CONTRIBUTING.md to provide the new equivalents alongside the old way, which should allow you to continue your current workflows and have a reference for migrating, if you should choose to.

I don't think make lint should fail because of anything here, but the Makefile could be rewritten to only need uv to be installed.

[tsalo]

Plan from today's devs call:

1. I will merge Add 'exclude' option to t2smap workflow #1248 and make a new release.
2. I'll address the merge conflicts in this PR.
3. I will merge this PR and, in the near future, make an alpha release so everyone can test out this approach.

[effigies]

Quick question: Do you actually want the pre-release checks? The idea there is that you can see failures coming down the pipeline, but it may be annoying to get red checks because numpy releases something breaking and you don't have time to deal with it yet.

I can see a few options:

1. Drop the pre-release checks and just deal with issues when it's time to upgrade the lock file.
2. Set the pre-release checks to continue-on-error, which will cause them to always be green, so you will need to actually look periodically or find some other way to notify yourself in a non-annoying way that there are problems coming.
3. I could put together something to cause the jobs to cancel on failure, so they'll show up as gray instead of green to let you know, but not show up as red.

[tsalo]

This is just for pre-release versions of dependencies, right? I'm fine with just testing new regular releases, like we currently have with dependabot.

Am I understanding your question correctly?

[effigies]

Yes. I can just drop them.

[tsalo]

@effigies thanks for dealing with the merge conflicts. Is this ready to merge?

[effigies]

Yes