mne-python new release

đź’¬ Support & Discussions
1

Hey team.

I am a member of the group NeuroFedora, where we all try to provide commonly used neuroscience tools for the Fedora Linux ecosystem.

I was wondering when would the next version of mne-python be released? We, at Fedora, are shifting to Fedora 35 which makes use of Python3.10 and there have been some deprecation errors from scipy.linalg.pinv and scipy.linalg.pinv2. These cause the tests to fail, and hence we are not able to provide python-mne for Fedora 35 for now.

I can see from the GitHub repository that this particular issue has been fixed, and hence we are waiting for the next release. Would love to upgrade mne-python for Fedora 35 as well :smiley:

Cheers

2

Thanks for the ping! Our usual release schedule is once every 6 months, and is due around the end of October. We can probably push out a point-release before then… cc @larsoner WDYT? I’ve actually already backported the pinv/rcond changes to maint/0.23 branch, but there may be other things that break under 3.10

3

We can try to add 3.10 to CIs and push out a point release. @Aniket-Pradhan when would you need a new release from us?

4

Thanks @drammock and @larsoner for the reply.

There is no urgent need for a release yet, it is just that the newly released Fedora 35 doesn’t provide any python-mne version for now. We can easily provide it as soon as you can provide a new point release. Fedora 34 still provides the previous stable release, so it should be fine.

No hurries in the process :smiley:

5

We need to at least wait for SciPy to support 3.10, and the point release made August 1st does not appear to:

NumPy at least just did a point release with 3.10 support:

So hopefully SciPy won’t be too far behind, then we can follow suit.

1 Like
6

@Aniket-Pradhan I pushed some commits to the maint/0.23 branch, is it easy for you to try building for example based on this commit:

If not and you really need a PyPi release first, I can push out 0.23.1 now, but if it’s easy for you to test on Fedora then please do so we can fix any remaining bugs, then I’ll push 0.23.1 to PyPi.

7

Hey @larsoner

I will test out the maint/0.23 branch by this weekend (preferrably Sunday, as I am currently out), and if there are any more bugs, I would ping you here.

If everything works out fine, then we could release the new point release.

Thanks for your help! :beers:

8

I pushed out mne · PyPI, feel free to test it. It’s easy enough to make another point release if needed

1 Like
9

Hey Eric

I am sorry I couldn’t get to you by Sunday.

I just tested out 0.23.1 on my machine, and I encounter only one issue. In particular, mne/tests/test_import_nesting.py test fails with the following log:

_____________________________ test_module_nesting ______________________________
mne/tests/test_import_nesting.py:43: in test_module_nesting
    assert code == 0, stdout + stderr
E   AssertionError: 
E     Found un-nested import(s) for ["scipy submodules: ['misc', 'sparse']"]

E /builddir/build/BUILD/mne-python-0.23.1/mne/datasets/utils.py:63: DeprecationWarning: `docformat` is deprecated!
E     scipy.misc.docformat is deprecated in Scipy 1.3.0
E       _data_path_doc = docformat(_data_path_doc, docdict)
E     /builddir/build/BUILD/mne-python-0.23.1/mne/datasets/utils.py:64: DeprecationWarning: `docformat` is deprecated!
E     scipy.misc.docformat is deprecated in Scipy 1.3.0
E       _data_path_doc_accept = docformat(_data_path_doc_accept, docdict)
E     
E   assert 1 == 0

After testing it out myself, I could see that after importing mne and scipy (v1.3.0), I could see the following submodules present:

>>> for x in sys.modules.keys():
...     if x.startswith('scipy.'):
...             print(x)
... 
scipy._lib._testutils
scipy._lib
scipy._lib.deprecation
scipy.__config__
scipy.version
scipy._distributor_init
scipy._lib._pep440
scipy._lib._ccallback_c
scipy._lib._ccallback
scipy._lib.doccer
scipy.misc.doccer
scipy.misc.common
scipy.misc
scipy._lib._util
scipy.sparse.sputils
scipy.sparse.base
scipy.sparse._sparsetools
scipy.sparse.data
scipy.sparse.dia
scipy.sparse._index
scipy.sparse.compressed
scipy.sparse.csr
scipy.sparse.csc
scipy.sparse._csparsetools
scipy.sparse.lil
scipy.sparse.dok
scipy.sparse.coo
scipy.sparse.bsr
scipy.sparse.construct
scipy.sparse.extract
scipy.sparse._matrix_io
scipy.sparse.csgraph._laplacian
scipy.sparse.csgraph._tools
scipy.sparse.csgraph._validation
scipy.sparse.csgraph._shortest_path
scipy.sparse.csgraph._traversal
scipy.sparse.csgraph._min_spanning_tree
scipy.sparse.csgraph._flow
scipy.sparse.csgraph._matching
scipy.sparse.csgraph._reordering
scipy.sparse.csgraph
scipy.sparse

Now I am unsure as to why sparse and misc submodules are being loaded. Is it because of some change in the upstream (seems unlikely) or in mne because of some change? Could you help me verify the same?

10

This is not really a critical bug (just affects import time) so if you can patch it at the Fedora end to decorate with @pytest.mark.xfail that seems like a fine workaround.

I am also a bit confused why you are running SciPy 1.3 with Python 3.10, I would expect SciPy 1.7.1 (latest release) to be what you’re testing against? And 1.7.1 was the one that had the deprecation warning that was the original topic – are you testing MNE-Python 0.23.1 against multiple Python and SciPy versions or something?

11

Ohh, I am really sorry, the scipy version was 1.7.0

I accidentally copied the version from the deprecation warnings (which basically meant that some feature was deprecated in v1.3.0) :stuck_out_tongue:

scipy-1.7.0 works fine with Py3.10 from what I can see. Furthermore, the update to 1.7.1 was reported on 02/08/2021, and I am expecting it would be updated soon enough.

Thanks for your help on this issue. I will mark the issue as xfail using a patch. Although if it affects import time then wouldn’t it be a Py3.10 issue? Since time is an internal library?

12

Sorry I should have been clearer, it doesn’t affect import time, what it affects is the amount of time it takes to import mne itself by a little bit (in this case probably a 50 ms or so), so I think we’re okay :slight_smile:

13

FYI @Aniket-Pradhan I just pushed out 0.23.2 with a fix for Python3.6, and while I was at it I made the test_import_nesting test more flexible so that you hopefully don’t need a patch anymore.

14

By checking the diff, I guess you forgot to commit the changes for 0.23.2. :stuck_out_tongue:

No worries, I will patch this specific test in the build script for now. Thanks a ton for your help!

Also, I misunderstood the “import time” earlier. Guess it’s not a good idea to reply to texts just after waking up :stuck_out_tongue: Thanks for clarifying that lol.

15

I also just tested building mne with py3.9 and am getting two more failures. I am guessing it would be because of some out-of-date library, which I am not able to pinpoint. If this is the case, it should be resolved when the out-of-date libraries are updated from Fedora rawhide (bleeding edge) to Fedora 35 (usually takes about a week).

Posting the failures below for your reference, if you can help find what was the issue for these. Here is the link to the complete build log.

=================================== FAILURES ===================================
_____________________________ test_describe_print ______________________________
mne/io/tests/test_raw.py:599: in test_describe_print
    assert s[0] == "<Raw | test_raw.fif, 376 x 14400 (24.0 s), ~3.3 MB, data not loaded>"  # noqa
E   AssertionError: assert '<Raw | test_...a not loaded>' == '<Raw | test_...a not loaded>'
E     Skipping 36 identical leading characters in diff, use -v to show
E     - .0 s), ~3.3 MB, data not loaded>
E     ?           ^
E     + .0 s), ~3.1 MB, data not loaded>
E     ?           ^
----------------------------- Captured stdout call -----------------------------
Opening raw data file /builddir/build/BUILD/mne-python-0.23.1/mne/io/tests/data/test_raw.fif...
    Read a total of 3 projection items:
        PCA-v1 (1 x 102)  idle
        PCA-v2 (1 x 102)  idle
        PCA-v3 (1 x 102)  idle
    Range : 25800 ... 40199 =     42.956 ...    66.930 secs
Ready.
_______________________________ test_object_size _______________________________
mne/utils/tests/test_numerics.py:305: in test_object_size
    assert lower < size < upper, \
E   AssertionError: 50 < 40 < 400:
E     {}
E   assert 50 < 40
16

I pushed out 0.23.3 with the actual fixes before I saw the comment about more failures. @Aniket-Pradhan can you try this branch to see if all tests pass?

If they do, I’ll merge it into maint/0.23 and cut maint/0.23.4!

1 Like