Packaging improvements

[mscheltienne]

Hi @cboulay! I see that you pushed quite a few nice changes. I have a couple of questions and tips for the packaging. I now see:

pylsl/pyproject.toml

Lines 67 to 68 in fb0ae2e

	[tool.setuptools.package-data]
	pylsl = ["lib/*.dll"]

Accompagnied with attempts to re-target wheels on windows 32 and 64. Unless mistaken, you are not building and packaging liblsl within pylsl, thus you should have a source distribution and a single binary distribution pylsl-**-py3-none-any.whl. Overall, you should be able to get rid of setup.py entirely and since you reverted to setuptools, specify the following pyproject.toml:

[build-system]
build-backend = 'setuptools.build_meta'
requires = ['setuptools >= 64.0.0']

...

[tool.setuptools]
include-package-data = false

[tool.setuptools.packages.find]
exclude = ['test']
include = ['src/pylsl*']

[mscheltienne]

And you might also be interested in the configuration of mne-lsl, We can't ditch the internal mne_lsl.lsl (equivalent to pylsl) since we now build liblsl and include it in the wheels and thus have a different lib discovery mechanism (+ other backward incompatible changes).

• mne_lsl-1.8.0-cp310-abi3-win_amd64.whl (427.0 kB view details)
• mne_lsl-1.8.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (656.6 kB [view details](https://pypi.org/project/* mne-lsl/#mne_lsl-1.8.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl))
• mne_lsl-1.8.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (626.4 kB view details)
• mne_lsl-1.8.0-cp310-abi3-macosx_11_0_x86_64.whl (501.7 kB view details)
• mne_lsl-1.8.0-cp310-abi3-macosx_11_0_arm64.whl (483.9 kB view details)

[cboulay]

Hi @mscheltienne ,

I tried to explain it in #95 but I can see how that got lost with all the other spam this repo was producing yesterday thanks to me.

In short, I want the win_amd64 and win32 builds to include liblsl (lsl.dll) because Windows users have a tougher time installing liblsl on the PATH. However, for ALL OTHER PLATFORMS, I don't bundle liblsl because it's relatively simple to build/install -- the strategy instead is to provide a useful error message when liblsl can't be found. Back when we were bundling the binaries with pylsl, there was always a platform or 2 users had that weren't covered and it wasn't worth the effort to support them all.

A couple questions for you:

• Will non 3.10 python's using pip still pickup your wheels, given that they are tagged cp3.10?
• How do you build liblsl on Mac with code signing so it isn't rejected by OS security? Or do users have to rebuild liblsl every time they pip install pylsl?

[mscheltienne]

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 recommends to drop python 3.10 in quarter 4 of 2024 (now) thus the next release will probably be tagged cp311. Same for conda-forge installs.

For macOS code signing.. good question and I don't have a definitive answer. I hope we are taking this into account (I'll have to check on a macOS laptop on Monday), my guess is that either cibuildwheel or delocate-wheel are taking care of it.

[mscheltienne]

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