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.

[johmedr]

Meeting Summary (10 March 2025)

Ongoing Work

• @arthurmitchell96 investigated setup issues on Windows and documented troubleshooting steps.
• @balbasty is working on fixing struct array iteration issues, ensuring compatibility with MATLAB structures.
• @Y-Bezs completed MNE-SPM conversion, allowing preprocessing in SPM and analysis in MNE. The main challenge was storing the trial matrix correctly.
• @suvadeepmaiti is testing Python virtual environments for SPM-Python and checking compatibility across different versions.

Release Planning

• The SPM-Python release is still planned for after MATLAB 2025a.
• The finalizing of struct types and iteration fixes is targeted for completion by next Monday.
• MNE-SPM conversion utilities need to be integrated into the repository before the release.

Key Actions

• Documentation improvements: Clearer setup instructions for Windows and environment configuration.
• Fix struct array issues: Adjust iteration behavior, ensure MATLAB compatibility.
• Finalize sparse matrix handling: Convert sparse matrices properly between MATLAB and Python, avoiding forced densification.
• Create a separate package for Python utilities: Discussion on whether to package additional functionality separately from SPM-Python.
• Improve MATLAB Runtime packaging: Investigate legally distributing an installer script to simplify setup.

Discussion

• Packaging MATLAB Runtime: Debate on whether an installer script could be provided to make installation easier.
• Struct array iteration: Issues with flat iteration, missing fields, and MATLAB compatibility need fixing.
• Long-term structure of SPM-Python: Where should Python-exclusive features be stored?

Next Steps

• Fix struct array iteration and finalize sparse matrix handling.
• Confirm integration of MNE conversion utilities.
• Decide on packaging approach for additional Python utilities.
• Meet next week to finalize before release.

[johmedr]

Key developments

• Type system was finalized and merged ([Enhancement] Matlab-like type system #21)
• Sparse array are now handled correctly
• nargout errors are now smartly handled in Matlab (fixes Catch errors due to nargout mismatch #26)

[johmedr]

Meeting Summary (18 Mar 2025)

Release Planning

• The SPM-Python alpha release is expected before the SPM Dev meeting next week.
• The release aims to be fully functional but marked as alpha to account for potential bugs.
• The MATLAB Runtime installer is being tested before public release.

Key Actions

• Improve documentation:
  • Update the GitHub page and SPM docs with tutorials.
  • Document type system usage and error handling improvements.
• Testing and feature completion:
  • @arthurmitchell96 and @Y-Bezs will finalize their features before the Dev meeting.
  • @balbasty will continue testing the new MATLAB Runtime installer for compatibility.
  • @johmedr will look into extracting M-Python type system into a separate package.

Discussion

• Versioning strategy:
  • Proposal to use post-release versioning (e.g., 25.01.1+2+3) for recompilation without changing core SPM code.
  • Agreement to tag stable releases for clarity.
• MATLAB 2025a compatibility:
  • Awaiting MATLAB’s official release before finalizing the SPM-Python release candidate.
• Runtime installation and distribution:
  • Tests are ongoing for Windows compatibility.
• SPM-Python documentation:
  • Plan to add a dedicated section on the SPM Docs site.
  • Discussion at SPM Dev meeting to decide on documentation structure.

Next Steps

• Finalize documentation before the SPM Dev meeting.
• Test the MATLAB Runtime installer for cross-platform compatibility.
• Complete refactoring of M-Python type system.
• Prepare a demo for the SPM Dev meeting.