Python pyproject package

[TheStaticTurtle]

Hi,

I've taken some time to adapt the python binding in order to be able to build wheels.

This includes:

• Writing the pyproject.toml
• Modifying the build script to manually link boost and adding the install statement to include the pyd into the wheel

Additionally I added a FetchContent for boost 1.89 int the deps cmake file so that the build process "just works". I have not tested if this causes an issue somewhere else!

I've successfully used pip wheel . to build the project with python 3.13 on windows.

[jcelerier]

Is there a way to identify the licenses of the project? They aren't a "OR" but a "AND"

[TheStaticTurtle]

My bad, didn't read enough of the readme.

According to the packaging guide

As per PEP 639 licenses should be declared with two fields:

• license is an SPDX license expression consisting of one or more license identifiers.
• license-files is a list of license file glob patterns.

So yes I can specify multiple licenses but I don't think I can specify where they apply. would the following be ok?:

license-files = [
    "LICENSE.md"
]
license = "MIT AND BSD-2-Clause"

[jcelerier]

yes thanks!

[jcelerier]

amazing, thanks for the patch!

• Is there a reason this requires scikit ?
• Do you know if this builds with uv too?

[TheStaticTurtle]

Hi,

As requested I updated the license and authors.

I also added an explicit check for readerwriterqueue in the cmake of the binding because it sometimes refused to build the first time for some reason and I don't know enough to figure out why.

Is there a reason this requires scikit ?

Maybe not but it's the easiest/fastest way I found to integrate cmake+nanobind in the packaging process.

Do you know if this builds with uv too?

It does.

There is an edge case where if it needs to download boost, it might fail due to the file path/name being too long. This can be fixed by tweaking the cache settings of uv.

[jcelerier]

thanks! all good for me to merge if the patch is good for you

[TheStaticTurtle]

It works for me with python build process, but it appears that the CI in place fails because I added the link to Boost::variant2 and Boost::container. How did it work before if boost wasn't linked?

It's clearly finding it (Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake) for the library, but not for the python binding.

I could add a sanity check the same way I did for readwriterqueue?

[jcelerier]

How did it work before if boost wasn't linked?

the huge majority of boost libraries are header-only and don't need linking, you can just link to the main boost target. If you specify components I think you have to add which components you are looking for in the boost find_package call, e.g.

 find_package(Boost 1.89 COMPONENTS Cobalt etc.)