Mathieu Scheltienne

I agree with @cbrnr I don't see much value in `lazy-loading` and I'm also concerned about the package maintenance and adoption. +1 to revert it.

@DrTodd13 Is that better? I'm not familiar with `numba`'s implementation / patterns, so guidance would be appreciated to properly resolve this deprecation.

Yes, this warning appeared in our `pre-release` CI which tests our dependencies against their nightly release. I suspect `torch` changed something that is now yielding this warning.

> IMO the problem is that we're still relying on FIFF. I'm pretty sure we've had this discussion before, but no one outside the small MEG community has ever used...

> Again, FIFF is a proprietary format, and maintaining just some constants is not a file format documentation. I don't think that an open-source package should be based on a...

And you might also be interested in the configuration of [mne-lsl](https://github.com/mne-tools/mne-lsl), We can't ditch the internal `mne_lsl.lsl` (equivalent to `pylsl`) since we now build `liblsl` and include it in the...

I missed #95 entirely 🙈 Alright that makes sense. For `mne-lsl`, no the minimum supported version is 3.10. `mne` is following the guidelines from the scientific python community, [SPEC 0](https://scientific-python.org/specs/spec-0000/)...

*The tag is `cp310-abi3`, thus anything above 3.10 is supported.

Comparing the build on the `manylinux` image and the version on the release page: Release page ``` mscheltienne@D-1027100163:~/git/mscheltienne/mne-lsl/src/mne_lsl/lsl/lib$ ldd /lib/liblsl.so linux-vdso.so.1 (0x00007ffd7c372000) libpugixml.so.1 => /lib/x86_64-linux-gnu/libpugixml.so.1 (0x00007f9da756d000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9da7200000)...