Automate SPEC0 adherence for dependency version management

[tsbinns]

Discussed with @drammock and @larsoner.

SPEC0 recommends a time-based policy for dropping dependency version support, specifically that support is dropped:

• for Python versions 3 years after release.
• for core dependencies 2 years after release.

Currently this isn't followed strictly, but @larsoner is happy to adopt this. In that case, it would be good to automate with a bot and have it run weekly or so.

There's existing code for finding the necessary minimal versions that could be used as a starting point: https://github.com/scientific-python/spec0-action/blob/main/spec_zero_versions.py
I'd be happy to work on extending this.

[tsbinns]

One question is what packages we would want to automatically manage:

• Just the core packages SPEC0 focuses on (numpy, scipy, matplotlib, scikit-learn, etc...)?
• MNE's main dependencies which are not SP core packages (e.g., pooch)?
• MNE's optional dependencies which are SP core packages (e.g., scikit-learn)?
• All of MNE's optional dependencies?

[larsoner]

To start I think anything we have to work around to keep it working makes the most sense. Really that's where the maintainability gains from SPEC0 come in. Like there's no point in adding a min pin to all optional dependencies -- just the ones that take active work to keep supporting old versions of (due to API changes, etc.). Off the top of my head that's numpy, scipy, matplotlib, pandas, and probably pyvista/pyvistaqt. Maybe one or two more but if we start there it's already a big maintainability automation gain I think.

[larsoner]

... incidentally, that's also maybe why we don't need to worry too much about dropping Python 3.10 support. There is no real gain from us in getting to 3.11 AFAIK. If we made wheels or something it would be worth it. But I don't think there are any 3.11 language features we'd want to immediately make use of (but I could be wrong!). This wasn't the case with 3.10 for example, where the isinstance and typing improvements over 3.9 made things cleaner for us.

[scott-huberty]

numpy, scipy, matplotlib, pandas, and probably pyvista/pyvistaqt.

@larsoner I think I'd advocate to start only with the the "core" Scientific Python packages that are listed in SPEC0 (and which we depend on). So that would drop pyvista/pyvistaqt from your list.

The flip side to dropping support for releases more than 2 years old, is that we should at least try to support all versions of those dependencies for the 2 year duration (?). But of all our dependencies, Pyvista seems to be the one with the most bugs that lead us to use aggressive pinning:

mne-python/pyproject.toml

Line 121 in 3cfac64

"pyvista >= 0.32, != 0.35.2, != 0.38.0, != 0.38.1, != 0.38.2, != 0.38.3, != 0.38.4, != 0.38.5, != 0.38.6, != 0.42.0",

In other words, if we dont commit to a SPEC0 like policy for Pyvista, then we are more free to pin to a version that is less than 2 years old right?

[larsoner]

In other words, if we dont commit to a SPEC0 like policy for Pyvista, then we are more free to pin to a version that is less than 2 years old right?

No, I don't think we should pin any more aggressively than necessary. It creates problems in dependency resolution for our end-users. The pins we have in place for PyVista are against versions we know are broken and/or do not work for our use cases.

Incidentally, we're effectively pinning != 0.38 with all those !=0.38.x pins, so we can simplify that pin somewhat in the meantime. But even better, if we did follow a SPEC0-like "2 years back" for PyVista, our pin could simply become pyvista >=0.42.1, since that came out in October 2023. So if you want a cleaner pyproject.toml that's one reason to include PyVista in the list of "we only guarantee 2-years-back" dependency support list for us.

[scott-huberty]

ur pin could simply become pyvista >=0.42.1, since that came out in October 2023. So if you want a cleaner pyproject.toml that's one reason to include PyVista in the list of "we only guarantee 2-years-back" dependency support list for us.

Yes I agree that a 2-year old pin would simplify this, but we are still free to do that without SPEC0? I guess the point I'm stuck on is that my understanding (which maybe is wrong) is that SPEC0 encourages packages to try to support "core" packages for 2 years, and it makes me concerned about how much work that will be for pyvista (given the history of bugs).. Unless you are feeling confident that the pyvista codebase is in a more mature state, and don't foresee this to be a problem

[larsoner]

I guess I'm advocating for a sort of "SPEC0+": I think we should try to support all of our dependencies for 2 years, and make exceptions only when needed (e.g., for versions that are actually incompatible and can't be made compatible, which was the case for PyVista 0.38.x for example, and is the case for some PySide6/PyQt6 versions). Practically this isn't in practice much more than supporting just SPEC0 itself because usually the core deps are the ones that break stuff. If you look at PRs to deal with pip-pre, deprecations, and API changes, I'd estimate it's at least 90% numpy/scipy/pandas/matplotlib. So not too much effort for us to just say "let's support 2 years back for all dependencies".

I also think we don't need to and shouldn't add min pins to dependencies unless it makes our lives easier as maintainers/developers. For PyVista the 2-year pin simplifies things so we might as well do it. Hence why I think it's worth lumping in with numpy, scipy, etc. for us in particular.

[scott-huberty]

Ok 🙂

[drammock]

+1 for adding pyvista to the list of deps where we don't guarantee compatibility after 2 years, and set a minimum pin accordingly.

There is no real gain from us in getting to 3.11 AFAIK.

I agree most of the 3.11 changelog is stuff that we are unlikely to use/want. But a couple things might be useful when we engage in a serious effort to annotate the whole codebase:

• the Self type annotation
• per-key TypedDict (Not)Required annotations

ExceptionGroup is also interesting but I haven't really thought of a part of MNE where we'd benefit from it.

[larsoner]

@tsbinns feel free to start working on the bot if you want! You can make a PR of some action that runs on PRs and pushes to main for now for debugging and before merge we'll add a schedule etc.

[tsbinns]

@larsoner I have put together a preliminary script for updating the versions. Just having some difficulties with permissions for the workflow that calls this script pushing the changes to the PR branch.