Inquiry on short, medium and longterm plans for pyvroom

[ejwillemse]

First, I'm a big fan of pyvroom (and vroom by extension).

I'm curious to understand the short, medium and longterm plans for it. Especially given the coupling with vroom which is progressing very well under @jcoupey.

We are using it in two commercial pilots.

So a couple of questions:

1. @jonathf : what are your plans with the project? Is it active in your commercial applications, or more of a side-hobby project?
2. Do you wan to increase it's exposure and get more people involved?
3. Any ideas where's the best place for others (especially non-C++ developers) to contribute? Document, examples, etc.?

And then more vaguely, any idea where this should sit with all the other python based VRP solvers, and solvers with python wrappers, that are popping, such as:

• https://github.com/reinterpretcat/vrp
• https://github.com/Kuifje02/vrpy
• https://github.com/yorak/VeRyPy
• https://github.com/chkwon/PyHygese
• https://github.com/google/or-tools (with python wrappers)

[nilsnolde]

From my side (though by far not the primary author), this has unfortunately low prio for the time being. We still want to integrate into another FOSS app (QGIS plugin to be exact), but that's on hold as well for a few months now. We will get to it again, once there's more time for the cool stuff again.

I'm not very interested in the full API though. My only interest lies in

• having it packaged on PyPI so our QGIS plugin can easily auto-install it
• all platforms (not all Linux distros!;)) to support the full range of QGIS users
• a, still-to-be-developed, JSON API mimicking the the vroom-express HTTP API input/output

Those things are also what I can commit to maintaining, once we're actively going to integrate pyvroom, which will be rather around mid 2023 currently. I do most of that already with pyvalhalla so it's hardly an overhead.

BTW @ejwillemse you might be interested that one of our GSoC projects deals with giving OSRM the same treatment. Hope to find a good student to deal with it: https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2023/Project_ideas. In case anyone knows someone, spread the word, it's actually decent money, like 5400€ for 350 hours of work.

[jonathf]

Thank you. Most of the credit for this project has to go to @jcoupey as he is the mastermind behind the project.

I initially created it as a hobby project, but because of health reasons I needed to stop working on it. Unfortunatly I am not longer in the position to give this project time as a hobby as I have too much on my plate both profetionally and with family. That being said, I am working within the public transit sector and a window might open so that I can start working on the project again profesionally. It is an obvious candidate to be worked on profestionally and and I'm pushing for it in that direction so that can be the case.

So short term we are on maintainence mode. I fix bug and do tiny stuff. Medium to longer term, we'll see what happens.

As for the VRP solvers, @jcoupey might be the better person to answer.

[ejwillemse]

@jonathf : maintenance support is still a massive and critical contribution, so kudos/stars/appreciation for your willingness to do that. It makes me sleep a bit better given that I'm using pyvroom in commercial POCs...

@nilsnolde : thanks for the update on your plans. And for the link to GSoC.

From my side, even though I'm using the library in two commercial projects, my company is in an extremely uncertain/chaotic/stochastic/fighting-for-survival mode, so committing to anything is going to be insincere.

What I at least can commit to is to try and get some eyes on this project. I know a few small dev-shop companies that are hacking together open-source tools to provide routing optimisation service.

Lastly, I think a general discussion on open VRP solvers (even though I brought it up) is outside the scope of a single project like this. So let me ponder a bit about how and where to take that forward.

[jcoupey]

Nice to discuss this! It brings a few questions on what is required in term of maintenance: for example the last upstream release broke a couple interfaces (some constructors and internal function calls). I have no idea if/how this affects the bindings?

If the impact is important, maybe it would make sense to tag the pyvroom versions accordingly based on upstream versions (that's what we do for the Docker images). Also maybe simply in term of features/API it would be clearer to have some kind of mirror tagging.

@jonathf judging from the last tag (0.0.15) it looks like you still consider the bindings fairly experimental, what's your take on that?

[jonathf]

Good question. I just made a PR to see how the code would respond to update up to 1.12 (closest target the version pyvroom is based of).

Looks like it compiles fine, but the interface has changed. Shouldn't be too much work I think to update the interface assuming the C++ API haven't been changed much.

On a more general level, I'd like to note that I based pyvroom off the C++ API and not the JSON API, and found out later that there are small subtle differences here and there between the two. Correct me if I'm wrong, but it feels like the C++ code have some legacy interfaces that you are trying to move away from. As such pyvroom has inherented the same legacies as it wasn't obvious to me before reading the API docs what the interface was actually targeting.

So I would say the interface seems stable, but the aim back when had time was to align the code more with the JSON API. But if that isn't an issue, I guess it will be easy to get pairity with the C++ code and tag it accordingly.

[jcoupey]

Yes there are a couple changes in the C++ interface now and then. Nothing major but probably a pain to maintain in the long run, especially since we don't commit to not breaking it. ;-) See this disclaimer in the wiki and some background.

For this reason targeting parity with the JSON API could make more sense indeed, and also it may be more user-friendly to have a unified end-user experience across various contexts like pyvroom and vroom-express.

[jonathf]

2 updates from my end just now.

I've just merged an update to pyvroom to version 1.13.0 aligning it with upstream vroom.

I also got an go-head form my employer for using (py)vroom for a pilot project, so I'll will be testing and polishing the code a little throughout the spring.

[jcoupey]

That's great news! I did not mention the python bindings too much so far because I lacked visibility on the current state of the code (WIP, release?) and the maintenance. But now we have both a 1.13.0 release tag in sync with upstream and some time planned ahead. So if that's fine on you side, I'll probably do a bit of advertising on the python bindings, at least on Twitter.

[jonathf]

I'm tempted to ask you to wait. The code itself should be ready, but the docs are about 90 % of what it should be at I feel. But things take time and we might wait a while until everything is perfect, so yes, lets advertise.

Perhaps mention that the documentation is limited to pydoc, so suggest that dir() and help() are the best way to navigate the code for now.

[jcoupey]

Of course there is no hurry here and we can definitely wait a bit more if it helps, you're in the best position to decide!

the documentation is limited to pydoc, so suggest that dir() and help() are the best way to navigate the code for now

If that is something users should be aware of for now, maybe we should have this kind of disclaimer in the readme?

[jonathf]

That is an excellent suggestion. I've updated the README now.

Feel free to advertise the pyvroom at this time.

[ejwillemse]

As promised, I'll do a LinkedIn post as well; it's the only place where I have some broadcasting power.

@jcoupey, let me know when you've done the tweet, and I will link to it.

[jcoupey]

https://twitter.com/VroomProject/status/1638827195874390016

Maybe we can close this ticket now, we already got mid-term plans, a release and an announcement out of it. ;-)

[ejwillemse]

Agreed. Thanks for the discussion everyone.