yet another Python binding to OSRM

[nilsnolde]

Initially started (and almost finished) by @whytro during GSoC 2023, I finally got around to publish the package: https://pypi.org/project/osrm-bindings/.

It's implemented with nanobind and very close to OSRM C++ API, in fact there's no python code at all other than tests. I was surprise by how many OSRM packages there are on PyPI: https://pypi.org/search/?q=osrm. Name choice was getting pretty limited, osrm-bindings is meeh, but whatever.. It's still importing as osrm.

I was battling Windows for a while but didn't have the patience. Maybe someone else does. It's building but the tests are failing, I didn't make any attempt to reproduce & fix locally: https://github.com/nilsnolde/osrm-bindings/blob/c2a4563122ee6ebcec6ce0c0b6d486d0303df94d/pyproject.toml#L92-L97.

[DennisOSRM]

Thanks for posting this, and a big shoutout to @whytro for laying the groundwork during GSoC 2023! Great to see it finally land on PyPI.

The nanobind approach sounds solid, and the fact that it imports as osrm is a nice touch despite the name squeeze on PyPI.

Given how many OSRM related packages are already out there, it makes a lot of sense to work toward an official set of bindings. The next step I would love to see is getting it to build and pass tests across all supported platforms and Python versions, Windows included. If anyone in the community has the patience to dig into the Windows test failures, that would be a fantastic contribution!

Let us keep the conversation going here around what a path to an official binding might look like.

[nilsnolde]

Yeah I agree, it's much smoother to have bindings live in the upstream repo. Especially for versioning/releasing. I did the same with the Valhalla bindings a while back. What's particularly nice about publishing bindings is that it's a binary release for all (supported) platforms. They contain the relevant executables too and one doesn't even need python installed to install those, a simple wheel download from pypi is enough.

I'd be happy to do the leg work & maintain the same for OSRM bindings. I wanna get more involved anyways, I have some appetite for deep diving into new routing concepts:)

Anyways, in that case I'd also strongly recommend for Osrm to release regularly. I switched Valhalla to quarterly releases via GHA (posts a PR). Before that, we were also often having a year in between with tons of master commits unreleased. What do you think @DennisOSRM, should we have a similar GHA here?

[DennisOSRM]

Yes, regular releases via GHA is for sure on my plate. The goal is to have a regularly exercised release train that ships every month or so.

Let's see what we can do about the package name. 😉

[DennisOSRM]

Yes, regular releases via GHA is for sure on my plate. The goal is to have a regularly exercised release train that ships every month or so.

Let's see what we can do about the package name. 😉

Just added automated releases and put out v26.4.0. 😉

[nilsnolde]

hahah I thought you're joking with 26.4.0 😆

[nilsnolde]

will the next one be 26.10.0 actually?

[DennisOSRM]

Releases are done monthly now on a schedule. Every first of the month we get a new release.

[nilsnolde]

it did take almost a full day, but windows is working now: ha, posted this prematurely! will (hopefully) be successful in a bit

there's some problems when testing map matching on win: nilsnolde/osrm-bindings#40. I'd get to that while contributing the project to upstream OSRM. if you're not cool with that or have some early comments, let me know @DennisOSRM. so far I didn't even check if tests are executed on win in this repo's GHA.

I guess I should be able to finish also the arm variants for mac & linux tonight. windows arm is apparently also forced on everyone these days, but I won't touch that;)

[nilsnolde]

pheew, it worked ;) https://pypi.org/project/osrm-bindings/#files

FWIW @DennisOSRM I'd like to continue to publish only stable ABI wheels. so only python >= 3.12 would get the binary wheels installed on a normal pip install osrm-bindings (or whatever the final name will be). if a python < 3.12 attempts that, it falls back to an sdist, which most likely works out-of-the-box (meeh, probably not for linux/mac without conan, needs system packages for osrm build), will need to check when it's finished.

my reasoning is that python < 3.12 is not in wide use anymore: windows & mac can easily install any "system"-ish python and ubuntu 24.04 has 3.12 already (well-aged ubuntu LTS is kind of the baseline for me personally, though I don't use ubuntu).

we can have that discussion also when on the future integration PR..

[nilsnolde]

oops forgot to mention the benefit of "stable ABI" wheels: they're (supposed to be) stable across python minor versions. before that existed, we always had to build & publish one wheel per platform, per minor version. which ends up with a good 40 releases all together (incl more exotic archs eventually). with the SABI it's only one wheel per platform, so divided by 5 usually (amount of currently supported minor versions).

of course, and most importantly, it lessens the maintenance burden. we don't have to do anything when a new python minor version is released. of course, only until it's not stable anymore and they have to break it, which I'm sure will inevitably happen somehow. we just have to keep building with 3.12 until we can't, but even then it'll likely be just another max 8 releases.

[DennisOSRM]

Sounds amazing! Thanks for the uodate.

I will take a deeper look in the next few days.

[DennisOSRM]

my reasoning is that python < 3.12 is not in wide use anymore: windows & mac can easily install any "system"-ish python and ubuntu 24.04 has 3.12 already (well-aged ubuntu LTS is kind of the baseline for me personally, though I don't use ubuntu).

That sounds reasonable. In the past we oriented minimum supported compiler versions on latest Ubuntu LTS and Debian releases.