Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUILD: Switch to Meson for building #117

Merged
merged 92 commits into from
Dec 20, 2022
Merged

BUILD: Switch to Meson for building #117

merged 92 commits into from
Dec 20, 2022

Conversation

pastewka
Copy link
Collaborator

@pastewka pastewka commented Nov 29, 2022

Switched the build system from setuptools to Meson. Added pyproject.toml. Removed setup.py.

@pastewka pastewka changed the title MAINT: Switch to Meson for building BUILD: Switch to Meson for building Nov 29, 2022
@prs513rosewood
Copy link
Contributor

Seems that the tests are failing because pip still installs _matscipy.so as a standalone package despite my changes. I've had that happen on my machine and fixed it with a newer pip version.

With "-dirty" as version suffix, pip fails the wheels installation with the
following errors:

- pip 22.3.1 `WARNING: Built wheel for matscipy is invalid: matscipy-0.8.0.rc1.dev89+gb96ca41-dirty-cp310-cp310-linux_x86_64.whl is not a valid wheel filename.`
- pip 22.2.2 `WARNING: Built wheel for matscipy is invalid: matscipy has an invalid wheel, matscipy has an invalid wheel, multiple .dist-info directories found: matscipy-0.8.0.rc1.dev90+g0ebd368.dist-info, matscipy-0.8.0.rc1.dev90+g0ebd368-dirty.dist-info`

The wheels naming convention allows for a numeric build tag, so "-dirty" does
not work. With ".dirty" it becomes part of the version spec.
ImportError is too generic for trying to import ._matscipy, DLL problems can be overlooked.
@prs513rosewood
Copy link
Contributor

I've added a simple check to cibuildwheel that makes sure both the package and the compiled extension can be imported. Looks like it's working for every wheel, and I've separately tested the windows wheels on bare metal. If the macos wheels work the PR can probably be merged.

@jameskermode
Copy link
Member

thank you @prs513rosewood! Last time I checked there was still an issue with the Mac arm64 wheel, I'll test that again now.

This was linked to issues Dec 20, 2022
@jameskermode
Copy link
Member

jameskermode commented Dec 20, 2022

MacOS X arm64 wheel still doesn't install. The .so file inside is arm64, but both the metadata filename say its x86_64. It would also be nice to have arm64 wheels for other Python versions (3.8, 3.9, 3.10, 3.11 to be consistent with the other platforms). However, to make progress shall we decouple things by removing arm64 support from this PR and working on it in a new one, so as not to hold up releasing Linux and Windows wheels to PyPI?

@jameskermode
Copy link
Member

I've added a simple check to cibuildwheel that makes sure both the package and the compiled extension can be imported. Looks like it's working for every wheel, and I've separately tested the windows wheels on bare metal. If the macos wheels work the PR can probably be merged.

Thanks, good idea - but unfortunately this won't work for arm64 since they are cross-compiled on x86_64 (until GitHub get Apple Silicon runners which I did hear about somewhere as a future) plan. Another reason to work on arm64 in a new PR.

@jameskermode jameskermode mentioned this pull request Dec 20, 2022
@jameskermode
Copy link
Member

jameskermode commented Dec 20, 2022

I created #122 which is a copy of this PR and then removed the arm64 wheels from this one. If all CI Actions pass then this one should be OK to merge.

@prs513rosewood
Copy link
Contributor

The cibuildwheel test actually runs only for wheels built by cibuildwheel. I'm ok with pushing the arm builds to a separate PR, but before merging I'll make a quick change: Numpy recommands using oldest-supported-numpy as a build requirement instead of regular Numpy, to avoid backwards incompatibility (i.e. if the build system pulls a version of numpy at compile time more recent than the one available at runtime).

@jameskermode
Copy link
Member

jameskermode commented Dec 20, 2022

I agree with using oldest-supported-numpy - we also do it with f90wrap and quippy wheels (and I thought I'd done it here too but must have got lost in all the edits in this branch)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build Wheels Fail to install matscipy on Windows system
3 participants