Support for libosrm

[jonathf]

Solves #7, if it is possible.

[codecov]

Codecov Report

Merging #51 (9826301) into main (0bfd898) will not change coverage.
The diff coverage is 100.0%.

@@          Coverage Diff          @@
##            main     #51   +/-   ##
=====================================
  Coverage   79.0%   79.0%           
=====================================
  Files         28      28           
  Lines       1323    1323           
  Branches      20      20           
=====================================
  Hits        1046    1046           
  Misses       268     268           
  Partials       9       9           

Flag	Coverage Δ
binding	68.4% <100.0%> (ø)
python	92.1% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[nilsnolde]

Quick 2c: linux & mac might be okish in building time since deps are easily installed. Even here though it really hardly makes sense to build osrm on every tagged release or even on pushes (not sure what you’re planning exactly). It’ll almost never change so building once or twice a year or so is enough IME. That’s why I opted for in-repo dependencies (libs & includes) that I build locally and check into pyvalhalla repo. It could be built somewhere else separately and included via artifacts which is what I’ll look into in the future (ideally upstream publishes this artifacts, ie osrm-backend & valhalla which I can download and check in).

and I won’t even mention windows 😅

[jonathf]

Thanks for the input. Right now I'm just experimenting.

I also have very low hopes for getting this to work on Windows.

[nilsnolde]

This could get some new traction once we set up the OSRM Python bindings with the GSoC student. There we can solve the hard part of making the dependencies (incl OSRM) available for all platforms (either host them on a public URL or some Github artifacts or so).

[jonathf]

Cool. I look forward to see how this pans out.

[nilsnolde]

Some updates on https://github.com/gis-ops/py-osrm @jonathf :

• for Linux we're using a manylinux_2_28 image: https://github.com/gis-ops/manylinux/tree/osrm_python, where we install OSRM and its dependencies. I'd recommend smth similar here for Linux, we can't make that available for this project as this is using manylinux2014. I could maintain another version for manylinux2014 where I install OSRM and its dependencies, but then linking OSRM would only work with cibuildwheel, not in the current PR workflow. But maybe we can run that with container pointing to that new manylinux image? In that case I'm not sure if pre-made actions with uses would easily work.
• for OSX, we push the artifacts of OSRM to Github which you can pull. Then we'd only need to brew install lua tbb [email protected].
• for Win we definitely want to push the whole built conan dependencies including the OSRM binaries to Github artifacts

The Github artifacts have a retention of 90 days. We plan to put a cron GHA event on it, so it'll automatically rebuild. That'd make this repo quite dependent on the OSRM binding repo and it would need to keep up with the same OSRM version.

WDYT @jonathf ?

[jonathf]

Sounds like we are getting to point were we can explore what is possible. If you can explore what is possible on windows and perhaps macos, I'd be happy to give linux a shot.

[nilsnolde]

I have some time on my hands soon and I'd like to fill the following repo: https://github.com/gis-ops/valhalla-osrm-libs. I'd use manylinux2014 as base to compile dependencies & OSRM/Valhalla, then it should be compatible with most distros/manylinux images.