Add pyproject.toml

[MuellerSeb]

This PR enables installing the package with pip locally and should simplify the distribution to pypi and conda in the future.

[MuellerSeb]

maybe we should build wheels with cibuildwheel like we did with GSTools.

[adamreichold]

If I understand this correctly, this would limit distribution via PyPI to source distribution requiring Maturin and Rust on the target system? Why not build a single wheel that uses Python's stable API and would thereby work on CPython 3.6 and newer?

[MuellerSeb]

No. Wheels are still build and deployed. But the missing source distribution is now added.

[adamreichold]

Wheels are still build and deployed.

Ah, but only for CPython 3.9, right? Since this is not calling back into Python at all, I see little reason to restrict support from 3.6+?

[MuellerSeb]

When installing from source-distribution, only rust needs to be provided, since maturin is set as build backend and will be installed during the build process. This is the magic of the new pyproject.toml workflow. 😉

[MuellerSeb]

Wheels are still build and deployed.

Ah, but only for CPython 3.9, right? Since this is not calling back into Python at all, I see little reason to restrict support from 3.6+?

Wheels are build for py3.6 - py3.10 and pypy. This is done automatically by the maturin action. The pinned python version is only used to handle maturin. Before, there were all wheels build multiple times, since the pinned python version is not affecting the built wheels.

[MuellerSeb]

You can see all produced wheels in the provided artifacts when you go to the Github-Actions tab.

[adamreichold]

You can see all produced wheels in the provided artifacts when you go to the Github-Actions tab.

I think this is limited to organisation members.

[MuellerSeb]

For some reason macOS wheels are only build for py3.9

[MuellerSeb]

Guess we have to do it by hand for macOS, like in this workflow: https://github.com/milesgranger/pyrus-cramjam/blob/master/.github/workflows/CI.yml

[adamreichold]

Guess we have to do it by hand for macOS, like in this workflow:

Personally, I would still advise to enable PyO3's abi3 and abi-py36 to build a single binary wheel that works on CPython 3.6 and later (not sure how relevant PyPy support is). It will almost surely cost nothing as this crate does not call back into Python to do its job. And it will reduce the burden of deployment (and build time) in general by having fewer binary wheels.

[adamreichold]

For some reason macOS wheels are only build for py3.9

I suspect the reason is lack of Docker support on GitHub's macOS VM?

[MuellerSeb]

Personally, I would still advise to enable PyO3's abi3 and abi-py36 to build a single binary wheel that works on CPython 3.6 and later (not sure how relevant PyPy support is). It will almost surely cost nothing as this crate does not call back into Python to do its job. And it will reduce the burden of deployment (and build time) in general by having fewer binary wheels.

Just learned about that. Amazing. Will try to do so.

[MuellerSeb]

Worked like a charm. And we only have 7 artifacts.. nice!

[MuellerSeb]

@adamreichold, @LSchueler should we include a fix for #16 here?

[adamreichold]

@adamreichold, @LSchueler should we include a fix for #16 here?

I would prefer a separate MR. I think this one is ready for merging when @LSchueler had time to review it while tackling #16 could open up completely new avenues of discussion.

[LSchueler]

Thanks you two for putting this together! I was just super busy this week...

@adamreichold already told me about the abi3 support, but unfortunately I didn't have time to join your discussion.