Comments (10)
Sure -- I was going to say we need to look back to figure out the min version that's np2 compatible, but we could just say 1.7.0 since 1.6.x and older are unsupported anyway.
from mne-python.
Our policy has always been to only support one version back and no father. There are probably other breakages with other packages in 1.2 for example and it'll increase maintenance burden (potentially a lot) with little gain for end users I think to continuously monitor and fix those. So I'd rather continue not to update anything father back than 1.7.
from mne-python.
Also I think that might be a misreading of SPEC0. I think it is meant to say that a MNE released today should work with latest NumPy back to the one from two years ago, not that MNE released version from two years ago should be continuously updated to work with NumPy from today.
from mne-python.
Our policy has always been to only support one version back and no father
agree, and this is documented here: https://github.com/mne-tools/mne-python/blob/main/SECURITY.md (not super findable, but still)
I think that might be a misreading of SPEC0. I think it is meant to say that a MNE released today should work with latest NumPy back to the one from two years ago, not that MNE released version from two years ago should be continuously updated to work with NumPy from today.
agree.
from mne-python.
Also I think that might be a misreading of SPEC0. I think it is meant to say that a MNE released today should work with latest NumPy back to the one from two years ago, not that MNE released version from two years ago should be continuously updated to work with NumPy from today.
I completely agree with that, but from the point of view of a downstream package, it means that it should work with an MNE released today or 2 years ago. Yet an install of MNE from 2 years ago yields a broken install nowadays. What would be the fix for a downstream package then?
(1) ignore the issue, it's up to the user to know that if he runs mne
1.4.2 he can not run numpy
2.0
(2) ...? I don't have a (2), pinning to mne
1.6 or above is too much of a restriction.
from mne-python.
There are probably other breakages with other packages in 1.2 for example and it'll increase maintenance burden (potentially a lot) with little gain for end users I think to continuously monitor and fix those.
Agree as well, but numpy
2.0 might be kind of an exception as to how 'big' a breakage it is.
from mne-python.
from the point of view of a downstream package, it means that it should work with an MNE released today or 2 years ago. Yet an install of MNE from 2 years ago yields a broken install
ah OK, I see the dilemma now. If you want MNE-LSL to follow SPEC-0, then you either need to
- pin numpy yourself to whatever is MNE-1.4 compatible, or
- backport those pins on old MNE versions (as you suggested)
- pin MNE-LSL to use MNE>=1.6 (which you say is unacceptable?)
I don't want to "open the floodgates" on keeping old MNE versions patched, but indeed it would have been better to have had upper (major-version) pins back then.
So now the question is whether (1) or (2) is better/easier. I doubt MNE-LSL is the only downstream affected by this (just the only one telling us so far 😅), so I guess I'm +0.5 on actually backporting the pins.
from mne-python.
pin numpy yourself to whatever is MNE-1.4 compatible, or
I think this is fine. If you really want to use an old version of any library you're going to face issues like this. I don't think major libraries are planning to retroactively pin -- looking at a pandas release 1.5.x series from ~22 months ago for example:
>>> import requests
>>> out = requests.get("https://pypi.org/pypi/pandas/1.5.3/json").json()
>>> [ent for ent in out['info']['requires_dist'] if "numpy" in ent]
['numpy (>=1.20.3) ; python_version < "3.10"', 'numpy (>=1.21.0) ; python_version >= "3.10"', 'numpy (>=1.23.2) ; python_version >= "3.11"']
I also vaguely recall somewhere in the (long!) NumPy 2.0 discussions people mentioning how trying to retroactively pin like this ends up being not super helpful, because even you cut a 1.4.3
with a pin, 1.4.2
doesn't (and never will) so you can still end up with a broken env -- for one example, pip install mne==1.4 "numpy>2"
will still work, it will just install (the broken) MNE 1.4.2
.
Going forward we could consider a numpy<3
in our pyproject.toml
for example -- I think they recommend something like this officially.
from mne-python.
OK, that's convincing. +1 on numpy<3
in pyproject.toml
, and indeed pinning ourself to whatever is MNE 1.4 compatible sounds like the best approach.
from mne-python.
OK! So NumPy pins go in the downstreams. By the way @larsoner should we add MNE to numpy/numpy#26191 (ecosystem compatibility tracker)?
from mne-python.
Related Issues (20)
- interpolate_blinks docstring should mention the method of interpolation HOT 1
- Inconsistent handling and documentation of pupil size units HOT 10
- Dropping all channels raises "No channels match the selection" HOT 3
- MNE.NIRS/nilearn.plotting Errors HOT 8
- Misleading parameter description in `fit_transform` method of `CSP` and `SPoC` HOT 1
- Cannot open nedf file from Neuroelectrics HOT 4
- Should `fetch_fsaverage()` return a `Path`? HOT 8
- Add Missing Fields to RawEEGLAB and EpochsEEGLAB Classes HOT 3
- HTML repr tables have really bad text contrast ratios HOT 4
- all random code should use default_rng
- DOC: Contributor credit improvements HOT 1
- CSP `rank` parameter does not behave as expected HOT 2
- Replace `psutil.virtual_memory()` with our own implementation? HOT 2
- RFC: developer meta-environments HOT 3
- Checkmarks in `mne.sys_info()` look out of place on Windows HOT 9
- Add sensor size option for plotting iEEG electrodes HOT 2
- MEG data problem consulting HOT 16
- Typo in SSD documentation HOT 2
- [ENH] Blink detection based on pupil size HOT 8
- Return generated filenames when saving (splitted) instances HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mne-python.