Closed whytro closed 1 year ago
Thanks, I’ll have a look tmrw. It’s a bit of a pity that we have to configure nanobind with CMake (EDIT: or maybe it’s also better, eg win support, let’s see:)). Can you elaborate a bit on the building internals of scikit-build with nanobind (e.g. role of pyproject.toml)?
Sure! As you may be aware, pyproject.toml is the new format to replace setup.py - it takes the role of describing how the wheel should be built (ie. describing build requirements). So in this case, you can see that it describes scikit-build-core and nanobind as dependencies, but also defines a configuration block for scikit-build-core in the form of the [tool.scikit-build]
block.
Though the config block included currently is brought over from the nanobind documentation sample:
minimum-version
is a required version setting that provides some backwards compatibility as the scikit-build-core documentation states that it will "select older defaults to help ensure your package can continue to build".build-dir
states the build path, and opts into caching between builds (will use a temp dir if not set).wheel.py-api
in this case states that it's targeting for CPython3.12, for stable ABI builds.In the end, the flow simply goes via scikit-build-core looking at the pyproject.toml for the defined config parameters, then running CMake using the CMakeLists file.
I also think that CMake will be of benefit - here I decided to try the approach of only downloading building LibOSRM if it wasn't already installed, using FetchContent instead of git submodules (which would also avoid the issue of users forgetting to initialize the submodules).
Ok great, thanks a lot for elaborating! I'm cool with not having a setup.py and going for a much more modern approach.
I will take closer look a bit later, but after 5 minutes of looking into code it seems to LGTM. :)
Issue
Relevant to:
Adds install/build related files so that it can be installed via running
python3 -m pip install .