Use of the new Python API frontend

[stouch]

According to osm-search/Nominatim#3154 , I've been told that a new Python frontend fixes some issues in search query. What could I do to use it ?

Thanks

[stouch]

@leonardehrenfried @philipkozeny you may know what's this new API frontend is about ? Thanks a lot

[leonardehrenfried]

Sorry, no idea. I cannot follow upstream development very closely and simply package the releases once they are there.

[stouch]

@lonvia Actually I realized that even the current docs at https://nominatim.org/release-docs/latest/admin/Installation/ dont mention this new frontend and still explain how to expose via PHP. So I guess in this repo we need to wait the official docs release of new API frontend

[mtmail]

4.2.3 is the current stable Nominatim release https://github.com/osm-search/Nominatim/releases Nominatim is slowly being rewritten from PHP to Python (https://nominatim.org/2023/08/13/going-live.html). osm-search/Nominatim#3154 describes the next version (4.3.0) that can also be installed if you use the git master branch. Nominatim version 5.0 will then have all PHP logic removed.

It's my understanding that the nominatim-docker project only creates Docker images for stable releases.

You'd need to wait for Nominatim 4.3.0 to be released. (and the Docker image being available after). Or you can install Nominatim without Docker from the git master branch.

[mtmail]

@stouch Documentation of the current/master/unreleased software is at https://nominatim.org/release-docs/develop/ (It's a new layout, too)

[carlomion]

Is #507 still active? Otherwise I would like to open a discussion on what would be the best approach for integrating a Python server inside the current container.

Should we just start the gunicorn process in the startup script (as done in #507 (comment))?
I would like to point out some shortcomings of the provided approach, for instance the fact that starting the Python process from Bash skips any process manager, and leaves the Python server free to crash unexpectedly and not be reachable until a restart of the whole container.

Maybe a more flexible and robust approach is to separate the web server from the DB in two separate containers (an approach that has been tried multiple times, see for example #494, #362, #245).
This would allow to define a gunicorn container that could be restarted automatically by docker itself in case of unexpected crashes, as well as providing more flexibility in separating the "service" layer from the "data" layer, for ease of resilience, HA, backup, etc..

[leonardehrenfried]

I would like to see us move to the Python API (well, we have to) but I'm not so keen on splitting this project into several containers. The main motivation for me to maintain it, is to have something dead-simple that doesn't require a lot of setup. I recognise that does goes against the usual "one process per container rule".

Since this is a request that we have seen (and rejected) before someone started a project that does exactly that: https://github.com/smithmicro/n7m Maybe you want to check out if it suits your need.