Switch to scikit-build-core, build wheels with bundled OpenBLAS

[roryyorke]

Fixes gh-164

[roryyorke]

this will need a version bump - 0.6.2? Will wait for review comments before pushing any changes.

[moorepants]

When distributing wheels that vendor binary dependencies, you'll need to package the dependencies' licenses as per each dependency's license terms. I think there is some standard tool to help manage this (as it has been solved for SciPy and others).

[roryyorke]

When distributing wheels that vendor binary dependencies, you'll need to package the dependencies' licenses as per each dependency's license terms. I think there is some standard tool to help manage this (as it has been solved for SciPy and others).

Thanks, I'll look into this.

SLICOT is also differently licensed to Slycot (MIT vs GPL), I suppose we should indicate that somewhere too.

[roryyorke]

[SLICOT is MIT]

Correction, BSD 3-clause: https://github.com/SLICOT/SLICOT-Reference?tab=BSD-3-Clause-1-ov-file#readme

[roryyorke]

this will need a version bump - 0.6.2? Will wait for review comments before pushing any changes.

I had already changed this to use setuptools_scm via scikit-build-core, so sdist and wheel versions are based on Git tag. This "just works" if there's git information available.

If we use this, I'll add tag' to the workflow trigger list in cibuildwheel.yml`, so the sdist + wheels are built on release.

Git archives

I did a test build from a git archive-generated tar.gz, and the build fails first due to not being able to figure out a version. When I added a fallback_version to [tools.setuptools_scm] the build gets further, but eventually fails because the archive doesn't contain SLICOT.

Do we need to support building from a git archive like this? Is it OK to require a build be either from the sdist or from a git working tree?

The .tar.gz / .zip files Github generates on release are git archive outputs (or very similar to).

[roryyorke]

When distributing wheels that vendor binary dependencies, you'll need to package the dependencies' licenses as per each dependency's license terms.

Fixed in 16e02d4

I think there is some standard tool to help manage this (as it has been solved for SciPy and others).

I added some code to the wheel building prep script to sort this out, I didn't go looking for a tool.

I have also changed the "license" field in pyproject.toml to account for all the dependencies, though I see other projects, e.g., scipy-openblas64, don't do that: the license field seems to only refer to the project's "own" code. scipy-openblas64 does include license files for all bundled dependencies.

[roryyorke]

@bnavigator any opinion on this?

[bnavigator]

Sorry for the delay, I was busy with life.

I think this is great! Finally some self-sufficient wheels on PyPI and a more modern build system.

I hope with future development of scikit-build and scipy we can get rid of the vendored symbol signatures, but for now this is a good procedure.

[bnavigator]

this will need a version bump - 0.6.2? Will wait for review comments before pushing any changes.

Warrants a 0.7 in my opinion

[roryyorke]

Sorry for the delay, I was busy with life.

No problem at all.

Warrants a 0.7 in my opinion

Fair enough. Will update.

On another project someone noticed I had setup my git wrong, and these commits all have a dud email address. I'm going to force-push amended commits to this branch.

This amending, and the change to 0.7, will get the CI to run again, and we can see if any of the many moving parts have changed enough to break the build.

@bnavigator could you please give me write access to Slycot on test.pypi.org? I'm user roryyorke .

[roryyorke]

When wanting to update the version to 0.7.0 I remembered #252 (comment)

I had already changed this to use setuptools_scm via scikit-build-core, so sdist and wheel versions are based on Git tag. This "just works" if there's git information available.

If we use this, I'll add tag' to the workflow trigger list in cibuildwheel.yml`, so the sdist + wheels are built on release.

I'm going to make this change and test it on my fork only.

Do we need to support building from a git archive like this? Is it OK to require a build be either from the sdist or from a git working tree?

I'm going to add a note to BUILD.rst that building from git archive won't work, and packagers should build from the sdist.

[roryyorke]

If we use this, I'll add tag' to the workflow trigger list in cibuildwheel.yml`, so the sdist + wheels are built on release.

I'm going to make this change and test it on my fork only.

There's already a push trigger, which includes pushing tags, so this was already in (not sure if pushing a tag is the same as tagging from GitHub UI). I added workflow_dispatch as a trigger, so that we can rebuild all the wheels if the CI-generated artefacts have been deleted, or for whatever other reason. cc46628

I'm going to add a note to BUILD.rst that building from git archive won't work, and packagers should build from the sdist.

Done in f0df6ee

[roryyorke]

For the record here are checksums of files uploaded to PyPI; you can compare these with the checksums shown in the build action at https://github.com/python-control/Slycot/actions/runs/27596723460

151a51d2e1b5025249ba869b6cac87060b4d435f84d070006e62476ed0e92b91  slycot-0.7.0-cp310-cp310-macosx_14_0_arm64.whl
ada70c043ae62762db7dc1a6e95969fd07ebcb1179d42f221b6f2ce5bede5d7e  slycot-0.7.0-cp310-cp310-macosx_15_0_x86_64.whl
3efe625feb1a96cfc7a51b2742a99fb1ac61d33d1a41a2b819f0ea060de6ed8b  slycot-0.7.0-cp310-cp310-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl
69c7f2004b16bd660a54c914df434a6d056b6fe375b042b06b6b87bd1853c091  slycot-0.7.0-cp310-cp310-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl
6506dbbbc2935ccce6a5178f41ec44ef0be2235b67bb96cb3cecc388b78769cd  slycot-0.7.0-cp310-cp310-musllinux_1_2_aarch64.whl
b2c5b8ba7a0e55f4fed19a8aa45cdc8ec0a4e6a296f9ed89ebda404b74e5d7b3  slycot-0.7.0-cp310-cp310-musllinux_1_2_x86_64.whl
abd1925ce1f0f1b8576d93136d114d36c211c5b9da5657d72ae26b2708f84dde  slycot-0.7.0-cp310-cp310-win_amd64.whl
6be91524ca60f981bd00081cb4a4f334bc82a1e19e8a40427796df0dd86d815f  slycot-0.7.0-cp311-cp311-macosx_14_0_arm64.whl
4baed66bb126ef3184e9d73e95f54c82ff8cb5f84ac35bae31133ff206ad0607  slycot-0.7.0-cp311-cp311-macosx_15_0_x86_64.whl
aad47ec7be49129865f7d423b53990ad93681211e91098b7a98c70d70bd63471  slycot-0.7.0-cp311-cp311-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl
24a42030f9f6d3a764369d688a9de7e716543eece8a20a06cfedb88102d843fd  slycot-0.7.0-cp311-cp311-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl
bbfe69f3c9d41d75d928723a90bbcee59ff8a03fea541366749dacc2682ec8b0  slycot-0.7.0-cp311-cp311-musllinux_1_2_aarch64.whl
f0884a1d7869334ef87e3ed54ac7e07c218f167dcb0f880ab40d0af92cf71bdc  slycot-0.7.0-cp311-cp311-musllinux_1_2_x86_64.whl
60913d73fd639c23d8c33c52a45ae241101cdbd6cb4d076d197d699727205ccc  slycot-0.7.0-cp311-cp311-win_amd64.whl
f113073165bd69618382f18d0b88a0df128b0e758a38f39a6c781c30cff78217  slycot-0.7.0-cp312-cp312-macosx_14_0_arm64.whl
a7170b12217819cd4933d4df5b1a6c53501c3b11e37f25211570253372406157  slycot-0.7.0-cp312-cp312-macosx_15_0_x86_64.whl
050c014af15fbf077c78e959e1ae523abce52443180acd92eab50c39abfcf051  slycot-0.7.0-cp312-cp312-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl
49d11efbf179597c7e5c90f28613bc18505e6cba7f48f947a16a2ac9c08dd8c3  slycot-0.7.0-cp312-cp312-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl
27c7658d224b1488585b7628a87cbb83b84a43e459de2a2f7370ee019be4f30e  slycot-0.7.0-cp312-cp312-musllinux_1_2_aarch64.whl
0236d2e70eda0b6c36b93d78705d50e9fcd0db1fa1f8e4544722facb23d8b265  slycot-0.7.0-cp312-cp312-musllinux_1_2_x86_64.whl
8f9171e68dd4140509b48993a9dc8acf171490188ccc17bd2a458b16600ecdb9  slycot-0.7.0-cp312-cp312-win_amd64.whl
00b98777ab35ea2dc89567c1ec786db04c2cd1a883da430264f8694ce3f5d870  slycot-0.7.0-cp313-cp313-macosx_14_0_arm64.whl
66e8415932b30bed7766f0c857957c8fa26e368950c6b66b2cbaadf57bbac48a  slycot-0.7.0-cp313-cp313-macosx_15_0_x86_64.whl
298b9077ff1cb947b25c01dd74b36a0e58851072de38da36f4c5c553350a6e24  slycot-0.7.0-cp313-cp313-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl
3f36acc6265e16a4d87c525dbd72b8678618e215664b79993a5cb5a093f27a94  slycot-0.7.0-cp313-cp313-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl
4780a43f0355d3170d03a9595c6ae29cebc91b4c40cd255a7ff49b04d3b5fcb1  slycot-0.7.0-cp313-cp313-musllinux_1_2_aarch64.whl
b6c46a8bf07571f681d34a8ed06e53aceecf7ceffe3c057cf6f3516eba3c6313  slycot-0.7.0-cp313-cp313-musllinux_1_2_x86_64.whl
0323d2d783b3b924221c7259ba0f54bb37923e0c720e844feb06d4d608d7a302  slycot-0.7.0-cp313-cp313-win_amd64.whl
f9c883335db8206c036f341fc9e144eb78024039f786a2a44fe9cf2178bacb36  slycot-0.7.0-cp314-cp314-macosx_14_0_arm64.whl
c357e7f7e0582717753dca3aed9a1bc9ce626ac7e29d7151b9512a311bbec603  slycot-0.7.0-cp314-cp314-macosx_15_0_x86_64.whl
4c8eb586eca8daf55ce5454f57d80d83a575719bf746640730a7072a5c1d3910  slycot-0.7.0-cp314-cp314-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl
665d26c8c140773bf579fc133aecd7d6c2c9d181b3cb118f7357d55a82e9287d  slycot-0.7.0-cp314-cp314-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl
0dabd96bb69d5dcbf5b5cce8cbf6997f4d9928ebbab02982c300bd04e0ae8bdf  slycot-0.7.0-cp314-cp314-musllinux_1_2_aarch64.whl
6a18a43b165013a467f44732355adb503511e78127c58e4de271e5314d49dc50  slycot-0.7.0-cp314-cp314-musllinux_1_2_x86_64.whl
57fd9d7afe9095915aca647a413ef66b159a41547a0a35c088fdf90e212aa137  slycot-0.7.0-cp314-cp314-win_amd64.whl
41ba13991982b0304520bf5115491d63f644389552eea62fc2ecbd21ef661001  slycot-0.7.0.tar.gz

[moorepants]

Nice work getting this all working!

[ilayn]

Congratulations @roryyorke for your persistence. Great achievement!

I'm still not able to spend time for OSS these days. But hopefully I will get the SLICOT translations done sometime soon that might ease your pain.