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