Pin maximum versions of dependencies in pyproject.toml

[tsalo]

Closes #1028.

Changes proposed in this pull request:

• Switch from setting minimum versions to maximum versions in the pyproject.toml. I used the versions installed from the last 3.12 CircleCI environment.

[tsalo]

The versions that work for 3.8 don't seem to be compatible with 3.12. Maybe we should drop 3.8 support?

EDIT: I switched to using the 3.12 versions and it all works now.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.51%. Comparing base (adf47bb) to head (d07ceaa).
Report is 51 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1029   +/-   ##
=======================================
  Coverage   89.51%   89.51%           
=======================================
  Files          26       26           
  Lines        3453     3453           
  Branches      630      630           
=======================================
  Hits         3091     3091           
  Misses        210      210           
  Partials      152      152           

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

[eurunuela]

Suggested change

	"mapca<=0.0.4",
	"mapca<=0.0.5",

[eurunuela]

I made a new release earlier, so we could already ping to that one.

[tsalo]

Thanks! I actually think I should leave it as-is, since dependabot should flag it for us almost immediately after this is merged.

[eurunuela]

Good point!

[handwerkerd]

I'm a bit confused by this. We know that tedana won't work with all older versions of these libraries. For example, tedana is looking for outputs from mapca that didn't exist in older versions. For mapca I given the issue/bug with the newest version of scipy in v0.0.3 it seems to be that we should want to set it to mapca=>0.0.5

Similarly, by pinning maximum versions we'll have to proactively update these version maximums rather than paying attention to when new issues arise.

Like I said. I am confused. I'm I misunderstanding the reasoning for this?

[tsalo]

We know that tedana won't work with all older versions of these libraries.

We can set minimum versions if you want, but I'm more worried about breaking changes from new releases than people accidentally installing old versions.

For mapca I given the issue/bug with the newest version of scipy in v0.0.3 it seems to be that we should want to set it to mapca=>0.0.5

I have kept it pinned to 0.0.4 to ensure that dependabot will open a PR soon.

Similarly, by pinning maximum versions we'll have to proactively update these version maximums rather than paying attention to when new issues arise.

That's what dependabot is for. Once a new release is made, dependabot will open a pull request with the new version pinned, and if CI fails then we'll know something in the new release doesn't work with our code, rather than surprising us with a user's bug report or failing CI on an unrelated PR.

[handwerkerd]

Besides my one suggested change. I think this is fine.

Having many PRs for version updates will be annoying, but I understand what it's useful & we can deal. I'm slightly concerned what happens if/when tedana becomes less actively maintained, but we can deal with that in the future.

[tsalo]

Setting both minimum and maximum versions seems to work well. I don't think dependabot can flag problematic minimum versions. We could probably create a minimum-version dependency set and run tests on that, like Nilearn does. That's out of scope for this PR though.

[handwerkerd]

Now that mapca is up to version 0.0.5 any clue how long it should take for the dependency bot to trigger?

[tsalo]

I had hoped that it would happen immediately after merging this PR, but it looks like we have it set up to run weekly. So, since dependabot was first added 3 days ago, I guess it might not run until 4 days from now?