Summary of SPM Python Dev Meetings

[johmedr]

We are starting this thread to document and share the key discussions, decisions, and action items from our ongoing SPM Python dev meetings.

The goal is to keep everyone informed, track progress, and provide a reference for contributors who may not attend every meeting.

Meeting Summaries

Each post will summarize:
• Main topics discussed
• Key decisions made
• Open questions or unresolved issues
• Next steps and action items

How to Contribute

If you attend a meeting and want to add notes or thoughts, feel free to comment below. You can also suggest edits or improvements to existing summaries.

Looking forward to everyone’s input! 🚀

[johmedr]

Meeting Summary (24 Feb 2025)

Ongoing Work

• @arthurmitchell96 is working on examples of using Dynamic Causal Modelling (DCM).
• @Y-Bezs is working on conversion between SPM-Python and MNE and integration with MNE.
• @suvadeepmaiti is working on examples of EEG processing.
• @balbasty presented a new type system that aims to reproduce MATLAB-like syntax in Python.

Release Planning

• The SPM-Python release is planned after MATLAB 2025a.
• The first release candidate is targeted for March 17th 🎉

Key Actions

• More usage examples.
• New unit tests are needed for the new type system.
• Integration tests are needed:
  • MATLAB Runtime compatibility (ensuring data transfer in/out of MATLAB works).
  • Loading and running MATLAB batch scripts as integration tests.

Discussion

We discussed how to best distribute compiled CTF files (which depend on a specific MATLAB Runtime version). Possible approaches:

1. Publish the CTF alone as spm-runtime-rXXXXx on PyPI, with spm-python depending on the latest spm-runtime.
2. Use semantic versioning (semver) for spm-runtime (e.g., v25.1r2024b) and manage dependencies in spm-python.
3. Implement a dedicated downloader for MATLAB and the SPM CTF.

No decision taken yet.

[balbasty]

Re CTFs, in the case of option (1), we could have the runtime be an optional dependency of spm-python. E.g., in pyproject.toml:

# spm-python/pyproject.toml

[project.optional-dependencies]
latest = ["spm-runtime-r2025a"]
r2025a = ["spm-runtime-r2025a"]
r2024b = ["spm-runtime-r2024b"]
r2024a = ["spm-runtime-r2024a"]

with the installation step taking the form pip install spm-python[latest] or pip install spm-python[r2024b].

Downsides are:

1. if no option is provided (pip install spm-python), no CTF will be installed. But a runtime check could detect this and ask the user to install with the latest option.
2. If multiple spm-runtime-XXXXx are installed, the most recently installed package silently takes precendence over previously installed packages (as they all use the same namespace).
3. We need to maintain as many pypi packages as matlab versions.

For point 2., I think that would be an ok behaviour (?). And I've tested the behaviour with the mock packages below:

- pack-a/
  |- setup.py        # setup(name="pack-a", packages=["pack"])
  |- pack/
     |- __init__.py  # __version__ = "a"
- pack-b/
  |- setup.py        # setup(name="pack-b", packages=["pack"])
  |- pack/
     |- __init__.py  # __version__ = "b"

And then

$$ pip install pack-a
$$ python -c "import pack; print(pack.__version__)
>> a
$$ pip install pack-b
$$ python -c "import pack; print(pack.__version__)
>> b
$$ pip install pack-a
$$ python -c "import pack; print(pack.__version__)
>> a

IMO it's better than "hacking" semantic versioning.

It also lets us have e.g. spm-runtime-r2024b depend on an hypothetic matlab-runtime == 2024b (or whathever the pypi compatible version string is) in the future.

[johmedr]

That's a good point, thank you for unpacking and testing all this. I think we should go with your approach, and we could package and execute the compiled Matlab downloader that is released through spm-standalone.